Tom Lane <tgl@sss.pgh.pa.us> writes:
> Gregory Stark <stark@enterprisedb.com> writes:
> > As an extreme example consider the new Linux release cycle. They have a
> > non-freeze period of a couple weeks, followed by months of frozen time. Users
> > who want to try out new features on different hardware can do so and often
> > turn up problems developers reviewing the patches missed. Developers spend the
> > months of frozen time working on new patches which, if they're ready on time,
> > all go into the queue in the first few weeks of a new release. If they miss
> > the window they'll make the next one.
>
> That doesn't seem particularly appealing for our purposes. What it
> sounds like is that all the development happens somewhere outside the
> main tree, and every so often everybody tries to land a bunch of large
> patches at once. That's going to be a mess if the patches interact at
> all, and it certainly isn't going to address my primary concern of
> encouraging a publicly-visible development process instead of having
> people hiding in a corner until they can drop a large patch on us.
Well that's basically what's been happening except they drop it on us a day
before feature freeze giving you a frantic month of trying to make it work.
The reason people go off on their own and develop without help are manifold
but I'm not sure the release process is one of them. They're not going to be
able to commit their incomplete code to the main CVS regardless of whether
there's a freeze or not anyways.
They can work openly on new features during the feature freeze and beta
period, they just won't have the expectation that they'll squeeze it into this
release. Instead they'll know that if it's ready for the patch landing period
it'll be in the next release.
> Here I agree - partly. With some continuing effort these patches could
> be in fine shape to apply by the time we branch CVS for 8.3 development.
> However, our traditional approach to beta period is that it's supposed
> to be a "quiet time" where people focus on testing, debugging, and
> documentation. Shepherding people who are doing major development
> during that period is likely to be a serious distraction from making the
> release ready and high-quality.
Well on the flip side you have months to do that work instead of having
pressure to rework whole patches in short order. Perhaps it helps that at
least in the case of Linux it's mostly different people handling the releases
and the raw development. I'm not sure we have enough manpower for that.
--
greg