Package Process for Discussion

[Ignacio Vazquez-Abrams]

On Thu, 2005-06-30 at 12:31 +0200, Warren Togami wrote:
> 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?

REVISED? NEEDSREVISION?

> Some other Misc. Thoughts
> =========================
> 1) "Claimed" status must automatically timeout after a certain amount of 
> time.  Maybe 12 hours?

Works for me. It requires reviewers to be on the ball, but doesn't
penalize them if something comes up in the meantime.

> 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.

Agreed.

> 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?

Sounds like a plan. That may also simplify the notification logic.

> 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.

The next revision of BZ is supposed to have RSS support IIRC. That could
be another option.

> 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.

Another excellent idea.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20050630/31041b96/attachment.sig>