Re: 8.5 development schedule
От | Robert Haas |
---|---|
Тема | Re: 8.5 development schedule |
Дата | |
Msg-id | 603c8f070906302120w6e168be4wdadd113038df25e4@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: 8.5 development schedule (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
On Tue, Jun 30, 2009 at 11:18 PM, Bruce Momjian<bruce@momjian.us> wrote: > Tom Lane wrote: >> > As for thresholds, I'd propose that we measure the size of patches >> > using "diff -u | diffstat". If the number of insertions plus the >> > number of deletions is >= 1000, then the patch is not eligible for the >> > final CommitFest unless it was submitted for the penultimate >> > CommitFest. This obvious discriminates against patches with a large >> > footprint that are not very invasive and in favor of those with a >> > small footprint that are more destabilizing, but it's a clean line in >> > the sand, and I think having such a line is better than trying to >> > apply human judgment to every case. >> >> Well, in the end it will come down to committers' judgements anyway; >> if someone thinks a patch is ready it will probably go in, regardless >> of size. But this gives us another tool for saying "no", so I'm >> agreeable ;-) > > I realize there is the perception that the large patches that were > eventually rejected held up the release, but for all the patches I can > think of, they were not rejected immediately _because_ we had other > valid patches to work on. Once all valid patches were applied, we were > quickly able to reject the large unready patches. > > So, rejecting the large patches earily would not have significantly > moved the release date earlier. I don't believe it. :-) If the large patches had been rejected earlier, the reviewers and committers who were spending time on them could have started spending time on other things sooner. I also believe, although I cannot prove it, that it would have increased the pressure to get the remaining items dealt with. When there are 100 patches, everyone can say "oh, well it doesn't matter whether I get this taken care of today, because there will still be 99 other patches". When there are 3 patches, that argument doesn't hold water. Another thing I'd like to improve for the next CommitFest is the communication between reviewers and committers. In the November CommitFest, I, and I think others, assumed that the committers were reading all of the review threads in detail throughout the process and that they would jump in when things got close to being done, or maybe when things got marked as Ready for Committer on the Wiki. That worked OK, but there were rough patches where things bogged down. As much as we may express opinions on the merits of certain patches, I think all of us non-committers are (certainly I am) loathe to avoid the perception that we're telling the committers what to do. But, I think it would be helpful to have periodic updates on what the different committers are currently focused on, how long they intend to be focused on that, and what they intend to focus on next; and I think it would be helpful for the CF mgmt team to make suggestions as to what patches we think are the closest to being ready to go or most in need of committer-level input. ...Robert
В списке pgsql-hackers по дате отправления: