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.
Advertising
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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
