Re: Last gasp

Joshua Berkus <josh(at)agliodbs(dot)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 current CF 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, whatever they 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