Re: 8.5 development schedule
От | Robert Haas |
---|---|
Тема | Re: 8.5 development schedule |
Дата | |
Msg-id | 603c8f070907011446s49cd90b8y59e11f3fecfc3b91@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: 8.5 development schedule (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Wed, Jul 1, 2009 at 5:01 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: > Bruce Momjian <bruce@momjian.us> writes: >> Kevin Grittner wrote: >>> However, even the *possibility* that this could be true is pretty >>> scary. If we need to effectively shut down new development for seven >>> months at the end of a release, in addition to the interim commit >>> fests, we'd better get a handle on why, so that can change. To what >>> do you attribute the extended time needed to handle the final CF? >>> How can that be made better? > >> We had many patches that had been through previous commit-fests with >> minor adjustments and we had to finalize them before we could close the >> final commit-fest. To be clear I am talking about patches that were >> eventually applied in 8.4, not patches that were rejected for 8.4. > > I think this is simply not in agreement with the facts. The patches > that caused the greatest amount of delay for 8.4 were the ones that > ultimately got rejected --- notably hot standby, sync rep, and > sepostgres. Now the fact that everybody knew they would take awhile This is also how I remember it. > provided some "cover" for other patches that weren't quite ready. > If we had bounced those three on Nov. 1 the commit fest would've been > a lot shorter. Probably some other things that did get in would've > gotten bounced too, but on the whole I think the project would have been > better off. It wasn't just the big patches that dragged on forever: for example, updateable views got submitted literally hours before the start of the CommitFest in a state where it did not even pass regression tests, I reviewed it, there was a loooong delay before resubmit, then it got committed, then it got reverted. If we had ejected that patch from the queue (for non-resubmission, if nothing else) early on in the process, it would have freed up at least three people's time (Tom's, mine, Peter's) to work on other patches that were in better shape and submitted sooner. One of the WORST mistakes that we made with the November CommitFest was to only assign reviewers to the small patches, figuring that the committers would look at the big ones. SE-PostgreSQL was not given a reasonable review for a very long time. What we need to do this time is start with the biggest patches and assign the most capable reviewers (committers, preferably) to those patches and then work down the list. This is another example of the uncomfortable dynamic between committers and everyone else: non-committers don't feel comfortable assigning committers to review patches, because who are we to tell the commiters what to do? But when the committers are the only ones competent to do that review, the result is a huge vacuum. We need to put some structure around this that works. I do agree, however, that rejecting more patches sooner (in particular, the ones that had been reviewed and found wanting) would have been the way to go and good for the project. > The long and the short of it is that there is always tremendous pressure > to include patches that are on the edge of being ready, because we all > know that bouncing them to the next release cycle will mean an extra > year before they're available in production. The dynamic in 8.4 was > exactly the same as it's been in the prior release cycles: we keep > slipping the possible release date and trying to get those patches > ready, and we don't give up until everyone agrees the release is just > hopelessly late. As long as we keep behaving that way, no amount of > schedule-setting or rule-making is going to change anything. Yep. > It comes down to somebody having the willingness to say "no" and the > authority to make it stick. Robert mentioned upthread that the > committers don't want to be seen as throwing their weight around, > which is quite true, but I have also noticed in the past that saying > "no" does not convince whoever is arguing that "this release will suck > if it doesn't have this feature". And there's always somebody arguing > that side --- usually several people. Yep. But having a review that clearly enumerates the reasons WHY the patch needs to be rejected is certainly more compelling than a blanket statement that the patch is big and invasive and therefore must have bugs, even if we haven't looked at it enough to find them. The blanket statement may be quite true, but it doesn't provide feedback to the patch author and so fails to accomplish one of the main purposes of the CommitFests, at least IMO. ...Robert
В списке pgsql-hackers по дате отправления: