Re: Feature freeze progress report

Simon Riggs wrote:
> On Thu, 2007-04-26 at 23:13 -0400, Bruce Momjian wrote:
>
>> Our community could probably handle a few of these complex patches, but
>> the volume for this release is significantly higher than previous
>> releases. The community is doing a good job of giving patch writers
>> feedback and new patch versions are getting generated. However, this
>> amount of patch churn is not normal.
>
> I think it is probably going to be normal from now on. We now a
> significant number of reasonably prolific developers.
>
>> I think the community has to come up with ideas on how to accomplish this.
>
> My thinking is to move to a two stage release process: Do one
> "production" release annually, and one "dev" release at the 6 month
> mid-point. That way each new release contains a manageable number of new
> features and we have a realistic chance of integrating them
> successfully. Support companies would then have the option to support
> both releases, or just the main production release. Leading edge users,
> of which we have many, would then benefit from more frequent additional
> features.

I'm not really convinced that this is good idea at all - it would lead
to further fragmentation of developer resources (likely more versions to
support and more frequent releases which to put quite a load on
developers by itself). And a lot of issues only get found in the field
and I'm unsure if a releases labled "dev" might get the critical mass in
terms of testing (if that would be true we would find most of the bugs
during beta imho).
99% of the people only use what is declared "stable" and already has a
number of minor releases - and the other 1% is already reading -hackers ...

>
> I would also suggest that 8.3 be labelled a dev release. We have a
> reasonable number of fairly invasive patches, so we need a mechanism to
> integrate them with reduced risk.

I would rather like to see patches we don't are confident enough in to
be dropped from 8.3 and moved to 8.4 - the goal should not be jamming as
much patches into a single release s we can (because they are proposed)
but rather putting those in that meet the quality bar and we trust in.

>
> With those two suggestions, the prod release would freeze on Sep 30 and
> the dev release on Mar 31. This would then put us into the same
> situation as Linux, where odd-numbered releases are dev and
> even-numbered are main releases. Everyone would understand our decision
> to take this action, as well as immediately understanding how this
> process will work in the future.

I don't want to see the current linux model - which is basically that
2.6 is a continous development trunk with snapshots (ie "releases") done
every few months that only get supported until the next release or so.
Note that all the distributions spend considerable amount of time
stabilizing those kernels and have to put additional resources into
maintaining those over the years because upstream is not doing that any
more.
Look into the recent discussion about releasing 2.6.21 with a number of
KNOWN regressions for example.

>
> By agreeing this now, we can then punt a reasonable number of patches
> back to the main release, later this year. The de-selected patches still
> have a second chance of making it into a release available in 2007 and
> this will diffuse the various tensions and difficulties we now have.
>
> Without this, we face a long wait. 8.2 took 4 months to go through beta
> and release, so 8.3 could well take 6 months. If we allow 8.3 to be a
> mega-release then it might take much longer than that: increases in
> complexity have a non-linear effect on software quality/robustness.
> Adding reviewers or committers isn't going to dramatically change that.
> IMHO the only sensible thing to do is to make releases more frequent so
> that each one is still a manageable size.

again - the bottleneck right now seems to be reviewer capacity coupled
with a large number of intrusive patches. So the most logical answer is
to drop those patches we are not fully confident in and try to get them
in during 8.4.

>
> The alternative is to somehow select patches to wait until the next
> release, a full year away. That is unlikely to be an easy process and
> nobody really wants to volunteer their own or others' patches.

see above

Stefan