[csw-maintainers] Code and package reviews

Philip Brown phil at bolthole.com
Sun Jun 26 02:48:35 CEST 2011


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.


>> 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.


More information about the maintainers mailing list