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@xxxxxxxxxxxx> http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
Attachment:
signature.asc
Description: This is a digitally signed message part
