Suggestion for standardization

[Michael Schwendt]

On Thu, 07 Apr 2005 14:06:11 -0500, Tom 'spot' Callaway wrote:

> The package review process is utterly confusing to me, so it can't make
> much more sense to everyone else.

Right. In addition to that, the sponsoring process is still confusing IMO,
too. It's an all-or-nothing process. Either you sponsor a person _and_ the
person's entire set of new packages. Or you don't sponsor the person at
all, because you don't have the time and interest to review all the new
packages and future cvs commits. [more at the bottom...]

> I propose that we adopt an "ACK" style system, where trusted
> contributors can ACK a package on review, two ACKs (maybe three?) will
> mark it as approved/sponsored. The trusted contributor providing the
> second ACK closes the bugzilla.

Doesn't work for me. There is no tracking in our current reviewing process
at all. I could not give my blessing to package reviews which don't
document _what was reviewed_. Except for a few old-school fedora.us dudes,
who have continued to post clearsigned approvals including source tarball
checksums, approvals for other packages either have been informal messages
or missing.

If I were to "ACK something", I would need to verify a person's review and
add my own checks. If I cannot see whether source tarball checksums have
been verified with detached GPG signatures (if available) or packages from
other big distributions or via diffs against previous releases, I would
need to assume that a packager and or reviewer trusts the upstream
project's download site ultimately. Similarly, without a comment on
perceived runtime stability of a packaged software version, I could not
verify the reviewer in that area either. I cannot simply assume that
binaries were built and tested by other reviewers, if there is no review
which documents such steps. Reviewing would be restricted to spec file
changes, which would be the only visible steps of the reviewing process.

It is not clear at all how to build up trust in such a scheme.
commits-list is excellent for monitoring activity in CVS. Reviewing, on
the contrary, so far has concentrated on spec adjustments and nitpicking.

> This presumes that the person submitting new packages for review is
> already listed as a Contributor with CVS access.

This doesn't fix the old fedora.us pitfall of lack of scalability.
So-called "trusted developers" could not include some of their _new_
packages, because they were in need of reviews, but didn't get reviews
for every package. Not even from fellow trusted developers. Nobody was
obliged to review new packages. Once a Fedora Extras Contributor is
sponsored and does have CVS access, who does all reviews? Contrary to
the initial "sponsors have to be willing to fix stuff if a sponsored
person goes crazy and breaks stuff", the SponsorProcess page in the
Wiki covers in more detail already what a sponsor's obligations seem
to be (and it's just a first draft of a document!).

> As is now, we're losing track of packages, no one knows when a review is
> sufficient. The old bugzilla fedora.us system worked well for this, and
> I don't see any reason why it shouldn't be adapted for FE.

Because it required reviewers to do more work, e.g. process the QA
checklist step by step, most likely required them to review a package
painstakingly and document reviewed items. And only few people were
willing to adhere to such a policy and do reviews, which looked as
if they were difficult.

> I think assigning the "QA" group to the trusted contributors maps well
> to the added responsibility of that role. If you're willing to sponsor
> people, then you should be willing to QA new packages.

This won't work. I sponsor _a person_, not all the future packages a
person might want to get included. In the decision finding process as
whether to sponsor a person or not, an initial set of packages and the
communication about them take a prominent role. But once a person is
sponsored and imports a couple of reviewed and approved packages, there
must be a way for the person to increase trust, so sponsors need not
review each and every cvs commit forever and can switch to guiding new
people into the system. 

This is not something to treat lightly.