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