On Thu, 2013-01-24 at 10:02 -0700, Tim Flink wrote: > On Thu, 24 Jan 2013 05:53:35 -0500 (EST) > Kamil Paral <kparal@xxxxxxxxxx> wrote: > > > > [1] http://tirfa.com/proposing-blocker-bugs.html > > > > * I agree that we need FAS<->Bugzilla integration, not just for this > > purpose, but for many purposes. I think a simple additional field in > > FAS where you could specify your Bugzilla login would be a great step > > forward. But ideally you would as well have to enter your BZ password > > once, so that the login can be verified. > > Yeah, ideally it would work that way. Submitting a patch to FAS so that > the bugzilla email is tracked would be one option that I think would > benefit more than just us but the problem becomes time to get such a > patch approved, accepted and into production. > > The current idea is to login with FAS and do one of two things > 1. populate the field with the user's FAS email (assuming that > bugzilla cc doesn't require a registered user) > 2. leave it blank as a required portion of the form so that the user > has to populate the field before submitting the blocker/FE > > If the user's bz email is different, that would be stored in the > blocker app's db. I hadn't thought about doing auth to check, though. > > I think this is a decent workaround for the time being - it isn't meant > to be the last method of proposing blockers but I couldn't think of > much else that could get done in the time we have. I'm open to > suggestions, though > > > But, do we really want to require Bugzilla accounts to get the > > ability to propose blockers? I don't know, just pondering aloud. > > I think so, yes. If someone wants to propose a blocker, they should be > willing to follow the progress of the bug on the cc list. If bugzilla > supports non-registered accounts on the cc list, I'm not as concerned > though because we could just add the FAS email to the cc list Hum, I thought we were planning to allow non-BZ-registered submission via this thing. I don't really mind either way, though. > > * I don't understand the "Release Number" in the HTML form much. > > We're working on a single release at a time. What's the purpose? > > The thought was to support proposing blockers against the next release, > not just the release which is currently under development. Not sure > it's incredibly important but that was the idea :) Yeah, it's for the case when, say, right now you want to propose a bug as a blocker for F20 Alpha right now. It'd be unusual at the moment, but it does come up later in the cycle. This is the same reason we create the blocker tracker bugs two releases in advance, not one. > > * As the first cut, I think the form is quite fine. But in the future > > I imagine we should have a bit different process and the form can > > adjust to it. My very rough idea: > > - A person can propose any important bug into "QA watchlist". He/she > > will acknowledge that the bug complies to our basic requirements > > (it's critical or affecting a lot of users, it doesn't concern just a > > tiny fraction of hardware, it can't be fixed post-release or > > significantly lowers user experience, etc). QA goes through the QA > > watchlist periodically, some bugs are removed right away, some are > > moved to the blocker/freeze-exc list, some are just kept an eye on. > > This is an interesting idea, my only concern would be about who's > watching the list and any implicit promises that we would be making > with regard to attention given to a bug. > > What would be the end benefit to implementing something like this? > Making the proposal process easier for people who aren't generally > involved in the blocker process? Having another grouping of bugs that > aren't blockers, aren't FEs but could be a problem and might be worth > testing more? Right, I'm not 100% sure what this would be for. That sounds suspiciously like the old Target tracker, which was dropped because it was being roundly ignored by everyone. Sometimes I feel a need for such a thing - 'hey, this is important, we should keep an eye on it, but it's not an FE' - but then I think, hmm, no-one paid any damn attention to the last such list we had, so... > > - A person can also check a box "This should be a release > > blocker" (the page explains what it is) and provides a justification, > > then it should have a higher priority for us in the QA watchlist. > > - A person can also select a milestone (Alpha/Beta/Final) for this > > blocker and (optionally) cite a particular criterion. Then it is > > proposed as a blocker right away, instead of going into QA watchlist. > > One of my hesitations in adding too much functionality to the blocker > tracking app right now is that we've been talking about a bigger > overhaul of the blocker process and I'd rather not spend huge amounts > of effort updating the tracker if we're going to end up moving to > something better. > > I have been purposely not been talking about it much until I was more > sure it could actually work, but I'm planning to propose a separate > system for tracking blockers which moves a lot of the data out of rhbz > and into a system we have more control over and could use for async > blocker discussions without polluting the bug. If we end up going that > route, I'm not convinced that the tracker app would make sense in its > current form - the UI is useful but the backend would probably be > migrated. Right, my general vague long-term plan was along these lines: you're planning to have a sort of super-blocker-webapp which handles submission, evaluation, tracking, and feeding update data back out to releng. And yeah, this is clearly a long-term goal. -- 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
