Heikki,
> 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
> Autumn.
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
easier.
-- 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
work.
-- 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.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco