amending the new package process

Miloslav Trmač mitr at redhat.com
Thu Jan 22 14:57:13 UTC 2015


> On Wed, 2015-01-21 at 12:10 +0100, Vít Ondruch wrote:
> > > I'd like to propose an amendment to allow
> > > bringing packages even if no reviewers are available (the typical case).
> > >
> > > Step 6: ... If the proposed package is not reviewed for 2 months, the
> > > package must be reviewed by the submitter, and a git module with the
> > > master branch will be approved.
> > The self review doesn't make sense, since I expect you did the package
> > to your best knowledge already and you really want second pair of eyes
> > to find any issues which slipped through your hands.
> > At least myself, I always looking for reviewer who cares to find every
> > issues I missed, challenge my knowledge and I'd be quite unhappy to
> > discover later that something slipped through review unnoticed.
> 
> That's wishful thinking. I proposed that rule in order to make apparent
> the fact that there are not enough reviewers and new packages are
> blocked in the queue. Ignoring the fact isn't going to make it go away.

True, there are not enough _voluntary_ reviewers.  But review swaps generally seem to work, or don’t they in your experience?

> > And there is nothing wrong with review swaps. You help others, they help
> > you.
> 
> That's good for you, but unacceptable to me. That way we penalize people
> who add packages.

Penalize in what sense?  It is unavoidable that when reviews are mandatory, overall the project’s contributors need to do as many reviews as new code additions.  That’s not a penalty for anything, it is just a task, or, to put it another way, Fedora’s choice of desired packaging quality level.

As to whether this quality level is warranted and those reviews are necessary, unfortunately, with the current packaging mechanisms, it probably is; because there are quite a few ways to screw up or to take shortcuts, and people who want to primarily focus on application source code instead of packaging tend to take these shortcuts at most opportunities (and historically Red Hat employees have been the sources of most of the most egregious shortcuts or worse).¹

Ideally, most of the guidelines, and thus the reviews, shouldn’t _exist_: we should have software either implementing the packaging functionality so that the easiest shortcut is to do it correctly, or at least software doing automated reviews.  But that just isn’t happening; apparently we have enough volunteers interested in writing and approving guidelines, but enough volunteers interested in writing the code to make the guidelines go away.²
    Mirek

¹ Admittedly it is inconsistent that the _only_ thing in the project which requires an independent review is packaging, and only the initial packaging at that.  OTOH there are plausible {reasons,excuses} for that: getting qualified independent reviewers for non-packaging code would be so difficult to make it not worth it, and once a packaging happens correctly it tends to stay correct because exactly the people inclined to take shortcuts are not likely to touch it if they don’t have to.

² Though, fedora-review exists, and hasn’t AFAICT replaced any item in the guidelines; so it is very well possible I am missing a part of the story.


More information about the devel mailing list