[csw-maintainers] Code and package reviews

[Maciej Bliziński]

2011/6/13 Philip Brown <phil at bolthole.com>:
> 2011/6/13 Maciej Bliziński <maciej at opencsw.org>:
>> 2011/6/11 Philip Brown <phil at bolthole.com>:
>>
>>> (...)
>>> 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 expect that your position can be described as "the release manager
>> position ensures that packages are always examined".
>
> yes.
>
>
>> 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.
>>....
>
> you took the time to write a lot of things in your email. Thank you.
> However,  while the things you wrote were "good", and "true"... they
> still did not concretely address the issue :(

I'm still unsure about your use of quotes or scare quotes, when you
quote the word good, which of the three you mean:

- something somebody else said that you quote here
- the literal: g, o, o, d
- not good

> I think the rest of what you wrote, can be summed up, with a minor
> insert, as follows:
>
>> 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.
>> [ So we **hope** that people will review packages]
>
> 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?

>> 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.
>
> It does not seem like it _adequately_ addresses the issue.
> Providing people an optional mechanism to improve quality, does not
> mean they will use it. "consistently".
> Providing people an optional mechanism to "get involved", does not
> mean they *will* get involved.
>
> 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?

Maciej