RFC: fedora.us bugzilla keywords

Michael Schwendt ms-nospam-0306 at arcor.de
Fri Feb 13 23:53:19 UTC 2004


On Fri, 13 Feb 2004 23:00:00 +0200, Ville Skyttä wrote:

> Further, it would be more "correct" process-wise if the initial package
> submission was the attachment. 

Which would also make it easier to find the most recent package in a
ticket. Scrolling up from the bottom to search for URLs in comments, which
announce an updated package, is not ideal.

> Then, reviews would be posted by editing
> that attachment, setting the status, and binding the reviews clearly to
> that particular submission/revision.  However, it would result in
> reviews being posted as the "edit attachment" comments, ie. again
> inlined.

Right now I don't really care for the exact procedure, since working with
an increased number of attachments might turn out to get a bit confusing
at times. Still it would be nice to have a way to locate reviews.

I consider it an unfortunate circumstance, that a few reviewers spend time
on a package which won't be published because it needs another
review. Often, after some time, the packager updates such a package even
after a first publish vote, and the reviewer would need to check that
update again and hope that another person joins to get the second
approval. Fine if fedora.us package queue becomes a source for working
src.rpms, too, but that's not enough.

> Some stuff to check:
> - Is it possible to create a query that does not match attachment
>   statuses for obsoleted attachments?

Shouldn't be a problem since attachment statuses can be taken back,
if need be, and queries can be limited on "open" tickets.

> - Is the Bugzilla web (and email UI) good enough for implementing this
>   or will it cause too much confusion to be worth it?

We probably need to test-drive this a bit. Not as a new policy, but as an
option.
 
> This is already even more complex than the "the review is the
> attachment" approach.  Dunno...

As a last resort, we might try the REVIEWED keyword, too.

Much more feedback from the target group of these changes is necessary.

-- 





More information about the fedora-devel-list mailing list