[csw-maintainers] Code and package reviews

[Maciej Bliziński]

2011/6/11 Philip Brown <phil at bolthole.com>:
> On Wed, Jun 8, 2011 at 6:09 PM, Ben Walton <bwalton at opencsw.org> 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/