12:52 p.m.
After FUDCon last weekend and some other conversations that I've had
(mostly over IRC), we're planning to implement a more user-friendly bug
submission system in the blocker tracking app.
I put the details that I have now in the form of a blog post [1] if
anyone is interested. The version that will be completed in
time for F19 testing will be pretty simple, in the interest of
actually getting it done in time. I don't think that we'll have any
great criteria display or integration but that is certainly on the
"wish list".
Everything is still very much in the early stages of planning, so
constructive comments and suggestions (or contributions) would certainly
be appreciated.
Tim
[1] http://tirfa.com/proposing-blocker-bugs.html
4:53 a.m.
* 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.
But, do we really want to require Bugzilla accounts to get the ability to propose
blockers? I don't know, just pondering aloud.
* 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?
* 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.
- 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.
11:02 a.m.
On Thu, 24 Jan 2013 05:53:35 -0500 (EST)
Kamil Paral <kparal(a)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
11:48 a.m.
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:
> > [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
3:36 a.m.
> > * 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.
Hum, I've never used that approach (proposing something for N+2).
If we want to keep the form as simple as possible, we might consider leaving that option
out. I guess operating on N+2 is something that not many people do and those people are
probably every capable of using the Bugzilla directly.
But this is just a cosmetic thing, definitely.
> > * 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?
Yes and somewhat yes. I find it unfortunate that we require all people to distinguish
between Alpha/Beta/Final milestones. Some bugs might be proposed for later milestones,
just because people are not so familiar with our milestone requirements (and which are not
easy to understand at all). So I'd like to give people an option to propose it to a
"general" tracker and we should fill the correct milestone. I'd also like to
give people some simplified criteria how to decide whether to propose the current bug as a
blocker or not.
I assumed we could combine this with a watchlist of bugs that are very inconvenient for
the user, but not really fitting the blocker process. The can't-install-rpmfusion bug
is a good example. So we would have a common pool of important bugs, some of them would
get 'upgraded' to proposed blockers, others would serve as a list of things to
push developers to fix.
I said it was a rough idea, I found it relevant so I mentioned it. I don't have it
well thought-out yet. I just wanted to briefly let you know what I've been thinking
about.
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...
I didn't know we had such a tracker before. Was it before my time, or was I simply
oblivious to it? It's a pity that it didn't work out well. Do you have some ideas
why it didn't work and how to make it work?
9:43 a.m.
On Fri, 25 Jan 2013 04:47:31 -0500 (EST)
Kamil Paral <kparal(a)redhat.com> wrote:
> 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)
Unfortunately this doesn't work, I just tried it. The email must
match a registered BZ account.
Thanks, I hadn't gotten around to testing that yet.
This still leaves a couple of questions, though:
1. Allow for blocker proposal without adding the user to the cc list
2. Allow users to specify a bugzilla email address without
authenticating against bugzilla
3. Require users to associate a bugzilla account with their FAS login,
verifying login with bugzilla. The email would be stored in the
app's database
I'm leaning towards 2 but am not against 3, assuming that we have the
time to actually implement and test it (and that it's possible).
Thoughts?
Tim
3:40 p.m.
On Wed, 23 Jan 2013 11:52:13 -0700
Tim Flink <tflink(a)redhat.com> wrote:
Everything is still very much in the early stages of planning, so
constructive comments and suggestions (or contributions) would
certainly be appreciated.
I have the first draft of the form done and up as a demo at:
http://209.132.184.160/blockerbugs/propose_bug
Please note that I am mostly looking for feedback about the form, the
checks that it is doing and the usability. Things I am aware of are:
- No bug list links on the menu
- no login
- no checks on the validity of bugzilla email addresses
- the bugs aren't actually proposed (validation is done, nothing is
actually sent to bugzilla)
Also note that all checks are done against partner-bugzilla instead of
the real rhbz. This is done so that any bugs in the code don't affect
the production bugzilla but it also means that the data is usually out
of date - recent bugs in production bugzilla may show errors about not
existing.
Anyhow, feedback would be appreciated.
Tim
5:22 a.m.
I have the first draft of the form done and up as a demo at:
http://209.132.184.160/blockerbugs/propose_bug
"Bugzilla User" field is confusing. What user? I'd label it "Your
Bugzilla login" or something similar.
11:04 a.m.
What is the point of the bugzilla ID?
I think that the best way to do it is to assign a number that will be
eventually the ID for the bug in this field if its needed on the form
(though i don't know how easy it will be to do it).
3:23 p.m.
On Tue, 5 Feb 2013 19:04:20 +0200
moshe nahmias <moshegrey(a)gmail.com> wrote:
What is the point of the bugzilla ID?
I think that the best way to do it is to assign a number that will be
eventually the ID for the bug in this field if its needed on the form
(though i don't know how easy it will be to do it).
I'm not sure I understand what you're referring to with bugzilla id
in this or what number would be assigned. Can you elaborate a bit more?
The bug id is the number/id of the bug being proposed as a blocker/fe.
The bugzilla user/login is used to add the proposer to the cc list of
the bug being proposed as a blocker/FE.
Tim
4:11 p.m.
OK, I think its being my mistake...
Is the bug id section is to define which bug is the blocker/freeze
exception?
If so then my comment is wrong on my part.
I thought we don't need the bug id (mixed up the idea of bug id with when
reporting on a new bug).
On Tue, Feb 5, 2013 at 11:23 PM, Tim Flink <tflink(a)redhat.com> wrote:
On Tue, 5 Feb 2013 19:04:20 +0200
moshe nahmias <moshegrey(a)gmail.com> wrote:
> What is the point of the bugzilla ID?
> I think that the best way to do it is to assign a number that will be
> eventually the ID for the bug in this field if its needed on the form
> (though i don't know how easy it will be to do it).
I'm not sure I understand what you're referring to with bugzilla id
in this or what number would be assigned. Can you elaborate a bit more?
The bug id is the number/id of the bug being proposed as a blocker/fe.
The bugzilla user/login is used to add the proposer to the cc list of
the bug being proposed as a blocker/FE.
Tim
--
test mailing list
test(a)lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
4 a.m.
OK, I think its being my mistake...
Is the bug id section is to define which bug is the blocker/freeze
exception?
If so then my comment is wrong on my part.
This is a good feedback. When I think about it, the label could be much clearer if we use
"Proposed bug number" (or similar) instead of "Bug ID".
5:48 p.m.
On 07/02/13 02:00 AM, Kamil Paral wrote:
> OK, I think its being my mistake...
> Is the bug id section is to define which bug is the blocker/freeze
> exception?
> If so then my comment is wrong on my part.
This is a good feedback. When I think about it, the label could be much clearer if we use
"Proposed bug number" (or similar) instead of "Bug ID".
We had fun trying to pick the label for that field in the initial UI
design. I think we went with 'Bug ID' in the end because that's what
Bugzilla calls it. It's kinda hard to predict what name will work out
best for the majority of people - I could equally see someone being
confused by 'Proposed bug number', really...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
1:50 a.m.
On Wed, Feb 13, 2013 at 1:48 AM, Adam Williamson <awilliam(a)redhat.com>wrote:
On 07/02/13 02:00 AM, Kamil Paral wrote:
> OK, I think its being my mistake...
>> Is the bug id section is to define which bug is the blocker/freeze
>> exception?
>> If so then my comment is wrong on my part.
>>
>
> This is a good feedback. When I think about it, the label could be much
> clearer if we use "Proposed bug number" (or similar) instead of "Bug
ID".
>
We had fun trying to pick the label for that field in the initial UI
design. I think we went with 'Bug ID' in the end because that's what
Bugzilla calls it. It's kinda hard to predict what name will work out best
for the majority of people - I could equally see someone being confused by
'Proposed bug number', really...
When I think about it I see what you mean.
How about "Bug ID of the proposed bug"? Or is it too long?
2:22 p.m.
On Tue, 5 Feb 2013 06:22:47 -0500 (EST)
Kamil Paral <kparal(a)redhat.com> wrote:
> I have the first draft of the form done and up as a demo at:
> http://209.132.184.160/blockerbugs/propose_bug
"Bugzilla User" field is confusing. What user? I'd label it "Your
Bugzilla login" or something similar.
Yeah, I'm not sure there is a great label for that field but "bugzilla
login" is probably better than user.
I've updated the form with the new label and added in some more checks
for already proposed blocker/fe bugs and updated the demo.
Tim
4091
days inactive
4112
days old
15 comments
4 participants
participants (4)
-
Adam Williamson -
Kamil Paral -
moshe nahmias -
Tim Flink