On Mon, 2015-01-05 at 13:19 -0500, Sudhir Dharanendraiah wrote: > ----- Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > On Mon, 2015-01-05 at 22:47 +0530, Sudhir Dharanendraiah wrote: > > > On 01/05/2015 10:18 PM, Adam Williamson wrote: > > > > In*theory*, if a bug's rejected as a blocker for one release > > > > it won't be a blocker for the next release either - remember > > > > Fedora doesn't use the RHEL system where bugs can be dropped > > > > as blockers for time reasons, in the Fedora system blockers > > > > are supposed to be unconditional. In practice we handwave a > > > > bit, but it's still > > > > generally the case that rejected blockers for one release > > > > won't be accepted for the next. > > > > > > Ah.. understood. thanks :) > > > > > > > Bugzilla doesn't make it super easy to find rejected blockers > > > > for a specific release, as you can't search for bugs > > > > which*once* > > > > blocked another bug but don't any more (bit of a shame) - but > > > > here's an approximate search, for open bugs filed in 2014 that > > > > have the 'RejectedBlocker' whiteboard: > > > > > > > > Yeah, dependent on whiteboard. Alternatively, we can use tracker > > > bugs for the various stages (Alpha/Beta/Final) of release. That > > > can provide a > > > tree view of bugs (can be blocker bugs in this case) targeted > > > for that specific milestone and the ones closed will strike out > > > leaving the ones that got dropped. > > > > > > > That's the system we do use, but the problem is that when we > > reject a bug as a blocker, we do it by making it not block the > > tracker bug any more. So to find those bugs, you'd need to do a > > search for 'bugs which blocked F21AlphaBlocker / F21BetaBlocker / > > F21FinalBlocker once, but don't any more', but Bugzilla doesn't > > have that option. > > > > We *could* make it so bugs that are rejected as blockers still > > block the tracking bug (but just have the 'RejectedBlocker' > > whiteboard field added), but I think that'd be confusing and a bad > > idea. > > Oh yes, its a bad idea to keep them in that state forever :). I was > only suggesting to keep the bugs till it is reviewed. But anyway, > since blockers are not pushed because of time constraint, that would > make no difference either. Yep. As I said the system we have is actually exactly as you describe. There are tracker bugs for each milestone - you can see them listed at: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers the blockerbugs web app - http://qa.fedoraproject.org/blockerbugs/current - is handy for several reasons, but before we had it, we still used the same set of trackers. At that time we did indeed use the tracker bug tree views as you suggest, e.g. here's the tree view for 22 Alpha: https://bugzilla.redhat.com/showdependencytree.cgi?id=1043121&hide_resolved=1 some of the benefits of the blockerbugs app are that it distinguishes between proposed and accepted blockers (we had custom searches for this, but custom searches are kind of a pain) and pulls in info from Bodhi, so we know the status of the updates for each bug. I do remember back around 16-17, though, I'd just have the tree views open and keep refreshing them... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
