Signing off of patches (was Re: Not ready for 8.3)

Alvaro Herrera wrote:

> Sorry, I wasn't trying to say that we should follow the Linux model all
> that closely. I know there are regressions in the "point zero"
> releases, and that there are bugs.

This morning a friend IM'ed me a comment about Martin Michlmayr's PhD
thesis, which is about release process on open source projects. It is
an interesting read:

http://www.cyrius.com/journal/phd?reverse=yes

Now, I don't think we can apply any conclusions directly from his study.
But it got me thinking anyway; what can we learn from them? I don't
think time-based release is appropriate for us, because we already have
the time constraints, but it is not good because we allow some patches
to "starve" on patch queues, or we let the schedule slip.

Having the Linux process still in memory, I started thinking that maybe
what we need, is a sign-off process, whereby developer A reviews other
developers' patches, make comments, and when the commented-on developer
(call him B) has fixed the issues that A had, then A signs off B patch.
In return for the favor, B also reviews and signs off A patches.
Eventually this leads to more cooperation between otherwise independent
developers.

The point of all this is to have an incentive for developers to review
patches. And what better incentive than having a chance that other
developers will retribute by reviewing his own patches?

This doesn't need to be anything too formal; I think that just having
people feel that other people at least took a look at the thing and
there are no obvious, glaring mistakes could go a long way. (I have
this weird idea that I should not apply a patch unless someone else says
"hey, looks OK to me". Somehow, the mere lack of objections does not
increase my confidence.)

Opinions?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support