> We're having a short 8.3 cycle because we wanted to shift our release
> schedule from Autumn to Spring. That would get us back to releasing in
Er, no. We wanted to change the cycle to avoid having Feature Freeze occur at
midsummer (N. hemisphere) when many of our committers are unavailable due to
conferences or vacation.
Question #559: Would changing version control systems help us on this at all?
I'm specifically thinking of preventing bitrot; would using a decentralized
VCS allow patch authors to easily prevent bitrot on their own?
I do like the idea of a web management interface for patches. It has a number
of additional advantages:
-- Advocacy volunteers would know what's under development and thus what they
can talk about at user groups
-- Advanced users who are interested in a specific patch could download that
patch early, test it for their own applications, and supply feedback to the
community even before feature freeze.
-- A more organized queue would make backporting by the backports project
-- We could save the patches by applied date and index them, and then have a
place to point users when they ask: "When was X fixed? Do I *have* to
upgrade to 8.1 or just 8.0?"
-- It would make it easier to manage Google Summer of Code students and their
-- The status of a partially complete patch abandoned by its author would be
much clearer and thus more likely to get picked up by someone else.
-- The patch manager could eventually be integrated with the Buildfarm to do
automated patch testing.
Overall, I think this would be an excellent direction to move for 8.4. As web
applications go, it doesn't even sound hard; I think I could write it if I
weren't on airplanes all the time.
PostgreSQL @ Sun
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly