Re: Feature freeze progress report

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