On Jul 7, 2009, at 2:14 PM, Peter Eisentraut <pete...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
