Re: Last gasp

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