[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Suggestion for standardization

Tom 'spot' Callaway wrote:
The package review process is utterly confusing to me, so it can't make
much more sense to everyone else.

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.

This is trying to solve the wrong problem. The process is confusing not because of the requirements but because of the lack of tracking.

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

Why does this distinction matter?

If a trusted contributor "NACK"s a package, they have to provide a reason, and the package cannot be submitted to CVS until the problem causing the NACK is lifted, or the trusted contributor withdraws the NACK.

Ideally, I'd like to do this in bugzilla.redhat.com. Perhaps we can
create a fedora-extras-QA component, and have new packages for review be
assigned to that. This component would go to all trusted contributors
(and/or fedora-extras-list) by default.

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.

Yes, the lack of database tracking is the key reason why the current process is confusing. We all agree that a fairly easy to implement ideal would be a stripped down Bugzilla interface with tickets, state changes and resolution. I don't know the status of the past proposed meetings between folks and dkl to make this happen. Anyone know?

The Red Hat folks should already be comfortable with the ACK system, so it gives the best of both worlds.

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.

What do you think? If people like the idea, I could document it this
weekend, and we can start following it.

NEW -> NEEDSWORK -> APPROVED -> COMPLETED REJECTED (with reason given like legal)

I think ACK or NACK is an oversimplification. We need explicit states something like below, and any of those steps can be skipped at any time. When you change a state give reasons just like regular Bugzilla comments.

Tracking is the key to making the process less confusing.
More and clearer documentation would help.
A simplified Bugzilla interface would help.

Warren Togami
wtogami redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]