Due to my screwed up sleep schedule while adjusting to another 12 hour
timezone change, I have not yet had a chance to talk with Dave in
real-time. These are a bunch of preliminary thoughts to expand on the
package review states that we created during the FUDCON2 meeting.
This design is heading towards the database driven package review
process. Everything related to a package will be tracked in a ticket
rather than scattered in the confusing mess that we have now.
I pose some new ideas and questions below. I also wonder if all of this
is possible with a custom bugzilla template. If you see anything
missing please speak up.
STATES FOR NEW PACKAGE REVIEW:
==============================
- NEW
new package submission, can be claimed
- PENDING/REVIEW
claimed, or reviewer must re-examine
Warren: Reading this back after the meeting, this makes no sense to me.
The other PENDING statuses mean "we're stuck until someone does
something". For this reason I think it makes no sense to call this
PENDING. Perhaps "REVIEW_UNDERWAY" better describes exactly what is
happening?
If the review is canceled or times out, should it go back to NEW or some
other state that means NOT_NEW_BUT_NEEDS_REVIEW_AGAIN?
If the reason for NEEDSWORK is fixed, should it go back to NEW or some
other state that means NOT_NEW_BUT_NEEDS_REVIEW_AGAIN?
I personally think it makes little sense to have a "NEW" state and
another that have almost the same meaning, because they are both in an
unclaimed state. Any thoughts? If you think we should have that other
state, what should we call it?
- PENDING/NEEDSWORK
review has identified problems,
packager must do work in order to proceed further.
- PENDING/LEGAL
review has identified potential legal issues,
legal must research in order to proceed further
- FAILED/LICENSE
packager must fix license and reopen
- FAILED/LEGAL
packager must fix legal issues and reopen
- FAILED/SEE-NOTE
packager must fix whatever is mentioned in the note and reopen
Warren: FAILED is a failure state where it would take a serious amount
of work, like convincing upstream to change a license, or convincing a
government to change a law, before the package is acceptable for Extras.
- PASSED/DONE (CLOSED) (RESOLUTION)
Warren: Passed is an indication of the package passing review, but
should we also track if the build is complete, signed and pushed? It
can be misleading to read "DONE" in a query when the package is not yet
pushed.
Dave, how do you think we should best represent Built/Signed/Pushed
here? Built and Signed/Pushed could be represented as two states, since
Build happens at a different time from Sign & Push which happen
together. fedora.us used differnet Bugzilla resolution states for this,
and it was convenient to query for and show up in rows of query results,
but I am hoping there is a better way.
Some other Misc. Thoughts
=========================
1) "Claimed" status must automatically timeout after a certain amount of
time. Maybe 12 hours?
2)
https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Extras&format=extras-review
This is the current submission interface. I think perhaps the Arch
chooser is not ideal here. There is no way of saying for example "i386
and ppc but not x86-64". It may be better to instead hide the Arch
field, and use flags for each arch?
The form could have all supported archs checked by default, and the
submitter could uncheck them explicitly if they want to be excluded.
3) There should be a field asking for only package name, while the
Summary field is to describe the package in a one liner. The current
"Help" for Summary doesn't encourage including the package name.
Dave is it possible to then within a query display "packagename -
Summary" automatically?
4) It appears that the form wants to submit to product "Fedora Extras"
currently. Shouldn't it submit to its own product, so we can keep these
bugs away from the bugs associated with actual packages with owners?
5) There are no "owners" of package requests, so there need to be
various auto-mailers setup, like a mailing list for people to subscribe
to watch new package submissions. Some people even want to see all QA
traffic, so this would be a different list. It would be nice if we
could use mailman's concept of sublists in order to automatically kill
the potential for annoying duplication, but I'm not exactly sure how
this would work in this case.
6) We want flags for target distribution. The flags would default
checked for "4" and "devel", and the submitter can choose more target
distributions if they wish.
Warren Togami
wtogami@xxxxxxxxxx
