2011/6/11 Philip Brown <[email protected]>: > On Wed, Jun 8, 2011 at 6:09 PM, Ben Walton <[email protected]> wrote: >> Excerpts from Peter Bonivart's message of Wed Jun 08 15:28:12 -0400 2011: >> >> Hi Peter, >> >>> To me, that's what those comments were about, that you yourself made >>> the case for us. You demonstrated why the current system is bad. >> >> And importantly, Maciej demonstrated how the new system can work >> well. :) > (...) > If anything, this incident shows *more strongly*, the benefit of > having at least 2 humans carefully look at a package before release. > > The "new system" does not in any way ensure that. > I firmly believe that it will shepherd in the exact opposite: a time > when the majority of packages will be released with only one person > ever having looked at them. > This is a bad thing. > > Now how about addressing the other part of my email, reguarding > ensuring that at least two humans examine a package?
I expect that your position can be described as "the release manager position ensures that packages are always examined". While on some level it is true, it still depends on there being a person who believes that examining packages is important, and who is willing to spend their time on it. Therefore, just saying "a human must examine all packages" doesn't solve the problem. If there's no one around willing to be involved, any written rules are in vein. Our aim is to build a culture in which peer review is one of the key elements. There needs to be an environment which encourages peer reviews and makes them easy. The first place is the devel mailing list. If you examine its archives, you'll see a number of discussions[1]. Some issues are very easy to spot there. For example, if there's a code commit adding a lot of overrides, it's a good indicator that the maintainer is facing problems and could use some help. The second place is the buildfarm database, which allows browsing package metadata[2]. It's the easiest way to inspect certain features of packages such as lists of binaries, their properties, required shared libraries, etc. Discussions usually take place on the devel mailing list, to avoid overwhelming the maintainers list. There are also the atom feeds[3], showing package updates. All the interested parties (not necessarily just maintainers) can monitor feeds in a reader, and react to updates of packages that interest them. It is important that the senior members of the project actively participate in code and package reviews, serving as a good example to more junior members. While this strategy does not claim to "ensure that X number of humans will always do Y", it addresses the underlying issue of getting people involved in the release process and quality assurance through peer review. Maciej [1] http://lists.opencsw.org/pipermail/devel/2011-June/thread.html [2] http://buildfarm.opencsw.org/pkgdb/ [3] Testing location: http://buildfarm.opencsw.org/~bwalton/ _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
