[csw-maintainers] Code and package reviews

[Maciej Bliziński]

2011/6/26 Philip Brown <phil at bolthole.com>:
> 2011/6/25 Maciej Bliziński <maciej at opencsw.org>:
>> I've received a complaint for mixing technical and non-technical
>> issues in one email.  Sorry about that.  Here's the amended version of
>> the email.
>>
>> 2011/6/13 Philip Brown <phil at bolthole.com>:
>>
>>> This is exactly the problem that I see.
>>> There have been a few people complaining about "lack of consistency"
>>> with the current release process.
>>> But how is a release strategy built around "hope", more consistent????
>>
>> Let's consider three separate issues:
>>
>> 1. Package review
>> 2. Policy development
>> 3. Policy enforcement
>>
>> The inconsistency that the proposal refers to, and attempts to
>> improve, is in point 3 above.  It seems to me that in your paragraph
>> above, you refer to point 1.
>>
>> How would you define consistency in the context of a human examining a
>> svr4 file?
>
> No manual human process can be perfectly consistent, I grant that.
> My position is that  "A person, or persons, have a specific
> responsability to at least glance at a package before release; if they
> dont, a package wont get released"  is **more** consistent than
>
> "all packages will automatically be released within 2 weeks.  Unless
> someone, maybe, possibly, decides to look at someone else's packages
> (without any prompting to do so) in that time window, and notices a
> problem, and files a bug about it"
>
> In the first example, it is guaranteed that a 2nd human has at least
> "touched" the package. guaranteed. that's 100% consistency right
> there.
> There is no such guarantee in the new proposal, as it currently stands.

The guarantee you mention, is a guarantee that a button is pressed.
There's no guarantee whether the human actually did anything or not.
Claiming 100% consistency is a bit of a stretch in my opinion.

The non-inclusion of reviews as a gating factor in the proposal is
intentional.  It might of course change - but so far, it has been
group's intention not to involve a human controlling package releases.

Peer reviews are an excellent mechanism to improve quality.  My
intention is to create an environment in which maintainers want their
packages reviewed.

>>> Some people.. including *you* Maciej... keep pressing the claims that
>>> everything should be automated, for "consistency".
>>> So why are you not automating a 2nd party validation check?
>>
>> Do you have any specific solution in mind?  How would it work?
>
>
> Since I have had no visibility into the new system, it is rather
> difficult for me to suggest a "specific" solution.
> In a more general view, it could work possibly similar to below:
>
>
> * new package drop into "unstable".   They are flagged
> somehow/somewhere as "needs review"
> * Any motivated maintainer can go look at [the list of packages that
> "needs review"], and....
>   (unsure what goes here, exactly. In an ideal-yet-simple world,
> perhaps click someplace, and have a browsable
>  interface to show layout of files, and optional click-to-view-file interface?)
>  If the maintainer wants to *really* check out details, they would
> just install it from the "unstable" tree.
> * if no problems seen, then after looking at above, the 3rd-party
> maintainer clicks checkbox, "yes looks okay to me".
>  package then gets cleared for migration to "current", after the 2
> week period also elapses.

How about a similar setup, in which there is no review based gating,
but accounting of reviews.  For example, there could be a tool
allowing maintainers to mark packages as reviewed and accepted.
Package review status would then appear on the web, in places such as
maintainer's page, and package pages in the buildfarm database.  It
would be a form a beneficial peer pressure, where maintainers would be
proud of having their packages reviewed.

Maciej