Tom Lane <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
