On Tue, 2013-01-22 at 11:09 -0600, Bruno Wolff III wrote: > On Tue, Jan 22, 2013 at 09:42:22 -0700, > Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > > >ProposedBlocker > >Blocker > >RejectedBlocker > >ProposedFreezeException > >FreezeException > >RejectedFreezeException > > > >And I assume it's still the case each of those has three modifiers: Alpha, Beta, Final. > > I think we can live without prefixes for the whiteboard. There could be cases > where a bug is freezeexception for alpha and blocker for beta, but those > could be handled by not marking the state for past the next type of > release. The simplicity of naming probably gains more than the extra effort > needed for a few bugs. Honestly I have concerns about the last few proposals: 1. (cmurf) "I would drop "accepted". It's a given if it's Blocker or FreezeException, that it has been agreed upon." No it isn't, because of the blocker review process. We need to indicate three states: Proposed Accepted Rejected We cannot do this with only the Blocks: field, which is why the whiteboard labels exist. In theory you could tell whether a bug which blocks the tracker is 'proposed' or 'accepted' by checking the comments, but that's a big inconvenience for a human to do and impossible for a tool - such as the blocker tracking webapp - to do reliably. We absolutely need the extra bit of metadata to indicate this status. A whiteboard field isn't the perfect way of doing it, but it works. Keywords are a bit better as you can't make errors entering them, but actually flags would be the 'best' way to do it in Bugzilla, as they give us the trinary state explicitly. If we're going to try and address this within the limits of BZ, we should probably request the RH BZ team create six flags for us (Blocker/FE for Alpha/Betal/Final), and use those instead of the Blocks: / Whiteboard: thing. But that involves relying on the RH BZ team, which past experience has told us can't be relied upon to get anything at all done remotely quickly. I can contact them and ask about a timeframe for such a thing, but for now I think it's worth taking the improvement we can already achieve. Using flags would also be a rather 'bigger' change than just twiddling with alias names and whiteboard field names, as it really does involve a significant adjustment in the mechanism of the process - we'd have to adjust a lot of docs, transfer all bugs from the F19 blocker bugs to flags, and do quite a bit of education to ensure people know about the New Way. It may be more of an F20 thing. Fiddling with aliases and WB fields is much safer in comparison as the fundamentals of the process are the same, and the actual bugs don't change. Summary: we really need to keep the Whiteboard fields for now. 2. (bwolff) "I think we can live without prefixes for the whiteboard. There could be cases where a bug is freezeexception for alpha and blocker for beta, but those could be handled by not marking the state for past the next type of release. The simplicity of naming probably gains more than the extra effort needed for a few bugs." Assuming you mean 'suffixes' not 'prefixes' - so your proposal is just to use Accepted and Rejected - then again, I don't like that. "There could be cases" where a bug has multiple states is putting it much too weakly - there are such cases, a lot of such cases, it's something we do all the time. We can't just handwave it away. I don't think the 'simplicity' of Accepted vs. AcceptedBlocker is worth that at all. In fact, a whiteboard field which just says 'Accepted' is probably more confusing than one which says 'AcceptedBlocker', if you don't know the process. 3. (kparal) "AcceptedBlocker RejectedBlocker AcceptedFreezeException RejectedFreezeException The latter is a bit long though, any other proposals?" This one's actually fine, but if you're worried about length, the alternative is to just go with what tflink initially suggested, adjusted for the new name: AcceptedBlocker RejectedBlocker AcceptedFE RejectedFE Shorter, less self-explanatory. Looking at them side-by-side, I'm actually happier with the long version. It's not like we're being charged by the character, and 'AcceptedFreezeException' is quite a lot easier to figure out the meaning of if you don't already know about this process than 'AcceptedFE'. (as a side note on all the camel casing - it's worth noting that BZ acts like Windows in this regard, visually it displays aliases, WB fields etc as cased, but internally it treats them as case-insensitive. If you mark a bug as blocking 'acceptedblocker' instead of 'AcceptedBlocker' it'll work just fine. If you search for 'rejectedfreezeEXCEPTION' instead of 'RejectedFreezeException' then again, it'll work just fine. So you don't have to be totally precise with the camel casing.) I think we've got this proposal to a really good place, though, and we all agree that it's a big improvement. In the interests of keeping the momentum going, unless anyone has any really big objections, I plan to put the change into 'production' today. We have a bit more time to argue about the whiteboard field names as we don't start using them until we start having blocker meetings, but here's what I plan to do today: 1. Give both the non-versioned aliases (AlphaBlocker, BetaBlocker, AlphaFreezeException etc) and new-format versioned aliases (F19AlphaBlocker, F19BetaBlocker etc) to the F19 bugs, along with the 'old format' aliases - the F19 bugs will have three aliases each for now 2. Create the F20 bugs (this is supposed to happen now as part of housekeeping anyway) with the new-format versioned aliases (F20AlphaBlocker, F20AlphaFreezeException etc) 3. Add new-format versioned aliases to the bugs for all previous releases (F18AlphaBlocker, F15FinalFreezeException etc) 4. Adjust the wiki docs (SOPs especially, and anywhere else I remember) for the new aliases and whiteboard fields - I'll just use kparal's WB field names for now, this is simple to change if we pick a different way of doing it 5. Ask the RH BZ dev team whether we could get flags created in a reasonable timeframe if we wanted to go that way All of these changes are quick, simple, non-invasive, non-destructive and entirely changeable and reversible, so I don't think there's a problem with Just Doing It. Again, if anyone has a big concern, please raise it in the next hour or so, or else I'll start cranking. Thanks much to everyone who chipped in and improved the initial proposal, I think this was a great example of FUDCon providing some momentum but not excluding people who weren't there from the process - the current proposal is clearly better than the one we initially came up with! If people have opinions on the idea of going the flag route, please do toss 'em in. It's worth noting that Tim's long-term idea for fixing the limitations of indicating blocker state with Bugzilla metadata is simply to do it in the blocker tracking webapp, which has quite a lot of advantages and is probably the best long-term option. So there's a question whether the benefits of using flags are worthwhile if it'll only be for a few releases until the blocker tracking webapp is able to do it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
