On Mon, Mar 4, 2013 at 11:50 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > Is that true of all commitfests, or only the last one in a cycle? If the > former, I think the existence of the "waiting on author" category belies > this point.
The original point of "Waiting on Author" was that a patch might need minor adjustments before it could get committed. And, generally, for the first few CommitFests, that's what happens. But in the final CommitFest, some people's notion of what a tweak in expands to include multiple complete rewrites. If a patch is basically OK, or only minor points are being discussed, it's appropriate to punt it back to the author and say, hey, fix these things and then we can commit this. But if the whole method of operation of the patch needs rethinking, then, in my opinion anyway, it should get pushed out to the last CommitFest. As for the last CommitFest, it's less that we should apply a different standard and more that people fight back against the same standard a lot harder when it means waiting a whole release cycle. >> Very little >> of the recently-committed stuff was ready to commit on January 15th, >> or even close to it, and the percentage of what's left that falls into >> that category is probably dropping steadily. At this point, if >> there's not a consensus on it, the correct status is "Returned with >> Feedback". Specifically, the feedback that we're not going to commit >> it this CommitFest because we don't have consensus on it yet. > > That is a fair point, and I think Tom has said something similar. But it > leaves open the question of who it is that is supposed to be implementing > it. Is it the commit-fest manager who decides there is not sufficient > consensus, or the author, or a self-assigned reviewer? It can be any of those. > I know that I certainly would not rush into an ongoing a conversation, in > which several of the participants have their commit-bits, and say "I'm > calling myself the reviewer and am calling it dead, please stop discussing > this." Or even just, "stop discussing it as an item for 9.3". Perhaps not, but you could certainly express an opinion, if you had one. If you express well-thought-out opinions a sufficient number of times, the idea is that (along with various other things) lead to you getting a commit bit, too. > I think the role of the commit-fest manager is that of a traffic-cop, not a > magistrate. But if we are going to have "Commitfest II: The summary > judgement", that needs to be run by a magistrate, as a separate process from > the ordinary part of a commitfest. I found that when I could spend 20 or 30 hours a week just managing the CommitFest, I could do a fairly good job separating the stuff that had a real chance of being ready with a modest amount of work from the stuff that didn't. But that basically involved me understanding, in a fair degree of detail, every patch in the CommitFest. Once I got my commit bit, that became a lot less practical, because understanding every patch in the CommitFest broadly and some of them well enough to commit them added up to more work than I could do. Also, that style of CommitFest management involved me spending a lot of time arguing with people who didn't want their patch punted no matter how well-considered the arguments, and the novelty of that eventually wore off. To be fair, many people were very reasonable about the whole thing - but the holdouts could suck up a huge amount of time and emotional energy. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers