Re: Last gasp - Mailing list pgsql-hackers
From | Peter Geoghegan |
---|---|
Subject | Re: Last gasp |
Date | |
Msg-id | CAEYLb_XEBrR6yUpKBfbRKEE8iXA0T0zKT-8nOteKpMGOrsAZ5A@mail.gmail.com Whole thread Raw |
In response to | Re: Last gasp (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: Last gasp
Re: Last gasp |
List | pgsql-hackers |
On 10 April 2012 18:28, Robert Haas <robertmhaas@gmail.com> wrote: > If we accept your argument that some > people simply cannot help themselves, then the only solution is to > make it cease to be a prisoner's dilemma, and that can only be done by > changing the incentives, which presumably means handing down > punishments to people who push their own patches forward at the > expense of others. Unless we care to choose a benevolent dictator, I > don't see any way to accomplish that. Well, I was really pointing out that people are somewhat forced into a corner by the current state of affairs, because committers are not typically able to look at anything in sufficient detail that isn't "ready for committer", particularly as we approach crunch-time - their time is simply too precious. By not marking the patch ready for committer, they are basically asking for their patch to be passed over, and they may be incapable of bridging the chasm between what really is their best effort, and what'd you'd consider to be the ready-for-committer gold standard. Some people cannot exclusively dedicate their time to their patch, or lack sufficient experience to meet that standard. > It's feasible to think that we might be able to streamline the process > of booting patches that are not close to committable at the start of a > CommitFest, and especially at the start of the final CommitFest. For > example, limiting patches to a small number of days in the "Waiting on > Author" state would help a great deal. But the more general problem > of people arguing that *their* patch is the special one without which > the earth will cease to revolve about its axis is more difficult to > solve, or that it's ready when it's really not, is more difficult to > solve. How would you propose we deal with that problem? As I've already said, I think that needs to be decided impartially, ideally by people who are removed from the engineering process. I don't mean that we'd get a marketing person to make those decisions - far from it. I just mean that some separation of powers can be a good thing in some circumstances. > I don't agree with that. I think that there are a few people who > don't now have commit bits who should be given them - in particular, > Fujii Masao and Kevin Grittner, both of whom have been doing > consistently excellent work for several years. I agree with you about both individuals. I hope that this happens sooner rather than later. > Giving more people the ability to > commit stuff will neither force them to devote time to it nor make > them qualified to do it if they aren't already. One major component of being qualified, is, of course, knowing what you don't know, and the risk of being left with egg on your face turns out to be a pretty effective way of preventing new committers from being too eager. Giving more people bits has a cost: in general, I'd expect it to result in a higher bug-to-line ratio when code is committed. However, not doing so has an opportunity cost: less code is committed, which may, on balance, result in an inferior release than what we could have had. Maybe you think that we have the balance perfectly right, and you are of course perfectly entitled to that view, as well as being perfectly entitled to having your opinion more heavily weighed than mine, but I'd like to see a dialogue about it at some point. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
pgsql-hackers by date: