Joshua Berkus <josh@agliodbs.com> writes:
> From my observation, the CF process ... in fact, all development
> processes we've had in Postgres ... have suffered from only one
> problem: lack of consensus on how the process should work. For
> example, we've *never* had consensus around the criteria for kicking
> a patch out of a commitfest.
True, but "put that decision entirely in the hands of the CF manager"
doesn't seem to me to be a workable solution. Half the time we
don't even have a CF manager, AFAICT. Now admittedly the opportunity
to wield absolute power might attract more interest in the position ;-)
but I don't think we want people who are attracted by that.
> Some suggestions:
> - for the first 2 weeks of each CF, there should be a *total* moritorium on discussing any features not in the
currentCF on -hackers.
We've tried that in the past, and it's never been adhered to very well,
and I think it's folly to assume that we'll get much better at it.
The nature of a mailing list is that there's a lot of noise. Even if
95% of the membership knows about and agrees with the restriction, the
other 5% will still post about non-CF stuff.
> - we should have simple rules for the CF manager for kicking patches, as in:
> * no response from author in 5 days
> * judged as needing substantial work by reviewer
> * feature needs spec discussion
These rules still seem to me to require a lot of judgment, hence
opportunity for argument. What's "substantial work"? How big a quibble
about the spec is big enough to get a patch booted?
> However, the real criteria don't matter as much as coming up with a set of criteria we're all willing to obey,
whateverthey are.
Ultimately, we're herding cats here. I don't think you're going to get
the community to suddenly be willing to march in lockstep instead.
regards, tom lane
