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 > * 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 :) > * 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? > - 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. Yes, I know I'm still being overly vague but I see the details of what I have in mind as being slightly orthogonal to this because any major change wouldn't happen in time for F19 unless the release is moved out much farther than I think it will. The only reason I'm mentioning it here at all is to give a reason why I'm hesitating to add too much functionality to any proposal facilitation stuff that we end up doing. Tim
Attachment:
signature.asc
Description: PGP signature
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
