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(a)redhat.com> wrote:
> >  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
> 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
> 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
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
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
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.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora