Proposing Blocker/Freeze Exception Bugs Through the Blocker Tracking App

[Tim Flink]

On Thu, 24 Jan 2013 05:53:35 -0500 (EST)
Kamil Paral <kparal at redhat.com> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/test/attachments/20130124/3d35de60/attachment.sig>