On Jul 7, 2009, at 2:14 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On Tuesday 07 July 2009 11:29:07 Brendan Jurd wrote:
>> We're now about a week away from the start of the July 2009
>> commitfest, and we need to make a decision about whether to start
>> using http://commitfest.postgresql.org to manage it, or punt to the
>> next commitfest and continue to use the wiki for July.
>
> I have the following concern: Likely, this tool and the overall
> process will
> evolve over time. To pick an example that may or may not be
> actually useful,
> in the future we might want to change from a fixed list of patch
> sections to a
> free list of tags, say. Then someone might alter the application
> backend, and
> we'd use that new version for the next commit fest at the time.
> What will
> that do to the data of old commit fests?
I don't see this as being much of an obstacle. I have migrated data
far more complex, and I venture to say that most of the rest of the
regular posters in this forum have too.
> With the wiki, the data of the old fests will pretty much stay what
> is was,
> unless we change the wiki templates in drastic ways, as I understand
> it. But
> if we did changes like the above, or more complicated things,
> perhaps, what
> will happen? Perhaps we simply don't care about the historical
> data. But if
> we do, we better have pretty high confidence that the current
> application will
> do for a while or is easily upgradable.
I suspect both are true, but in the unlikely event that we decide on
some massive change to the system, we can either run the DBs in
parallel as Tom suggests, or dump out the older data in Wiki markup
and post it on there. But I can't imagine what we'd want to do that
would even make us consider such drastic steps. Your example would
not be a difficult migration, for instance.
...Robert