Package Process for Discussion

[Warren Togami]

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 at redhat.com