FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 01-15-2008, 03:46 AM
"Jon Stanley"
 
Default Fedora bug triage - workflow proposal

Well, it was a great session at FUDCon. A lot came out of it, and I'm
going to put some of them down here. The work flow suggested below I'd
a FESco vote on, since it really affects you guys. This work flow was
discussed between myself, John Poelstra, and Will Woods at the Sunday
hackfest, and we agree that this is the correct way to move forward,
however, we want community input and buy-in on this, since it has
pretty far-reaching consequences.

Here is the lifecycle of a bug:

1) Reporter files a bug report, it originates in NEW state
2) Triage team looks at bug report, determines if dupe or
insufficient information exists to solve it. If there is not enough
information in the bug, then triage team puts the bug in NEEDINFO. As
you will see below, this state has a finite life cycle associated with
it.
3) Assuming bug survives through the triage team, it changes state to
ASSIGNED (triage team can put it in either NEEDINFO or CLOSED, as
appropriate). Note that per the definition[1], ASSIGNED does not mean
that someone has actually agreed to take action, simply that the issue
is well defined and triaged accordingly
4) Once a developer has taken responsibility for a bug and is
actively working on it, the state transitions to ON_DEV.
5) Once an update addressing a bug exists in Bodhi, and is pushed to
updates-testing, the status automatically transitions to ON_QA
6) When the update is pushed to stable, Bodhi optionally closes the
bug automatically. If the update does not auto-close the bug, it
transitions to NEEDINFO_REPORTER, with a comment explaining that the
update has been pushed to stable, and to update and test in the new
release.

Note that at any step of the above process, the maintainer can "fast
track" the bug, and change it to ASSIGNED. The triage team is not
going to look at bugs that are not in NEW or NEEDINFO state. On the
flip side of that, it is not a maintainer's responsibility to look at
bugs that are in NEW any longer. They can focus their energy on the
bugs that are ASSIGNED to them.

Also, maintainers should not be allowed to set priority on bugs.
Setting severity is fine. Only QA or releng should set priorities.
This allows us to look at things in a sane manner (which is impossible
now since severity and priority fields come from /dev/urandom
seemingly), and possibly lessen the reliance on blocker bugs (though
blockers are useful in their own right, so don't think that we are
going to eliminate them any time soon).

It was also decided that when a bug is in NEEDINFO for one month, it
will be closed. Maintainers would need to realize that putting a bug
in NEEDINFO is putting it on the fast track for closure.

I think that's all that I have to say on this topic right now, let me
know if I'm missing anything or this is complete hogwash

-Jon

[1] https://bugzilla.redhat.com/page.cgi?id=bug_status.html#verified

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-15-2008, 07:49 AM
Patrice Dumas
 
Default Fedora bug triage - workflow proposal

On Mon, Jan 14, 2008 at 11:46:36PM -0500, Jon Stanley wrote:
>
> It was also decided that when a bug is in NEEDINFO for one month, it
> will be closed. Maintainers would need to realize that putting a bug
> in NEEDINFO is putting it on the fast track for closure.

So what is the equivalent of NEEDINFO that doesn't put the bug on tracks
for closing?

--
Pat

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-15-2008, 08:06 AM
Hans de Goede
 
Default Fedora bug triage - workflow proposal

Jon Stanley wrote:

Well, it was a great session at FUDCon. A lot came out of it, and I'm
going to put some of them down here. The work flow suggested below I'd
a FESco vote on, since it really affects you guys. This work flow was
discussed between myself, John Poelstra, and Will Woods at the Sunday
hackfest, and we agree that this is the correct way to move forward,
however, we want community input and buy-in on this, since it has
pretty far-reaching consequences.

Here is the lifecycle of a bug:

1) Reporter files a bug report, it originates in NEW state
2) Triage team looks at bug report, determines if dupe or
insufficient information exists to solve it. If there is not enough
information in the bug, then triage team puts the bug in NEEDINFO. As
you will see below, this state has a finite life cycle associated with
it.
3) Assuming bug survives through the triage team, it changes state to
ASSIGNED (triage team can put it in either NEEDINFO or CLOSED, as
appropriate). Note that per the definition[1], ASSIGNED does not mean
that someone has actually agreed to take action, simply that the issue
is well defined and triaged accordingly
4) Once a developer has taken responsibility for a bug and is
actively working on it, the state transitions to ON_DEV.
5) Once an update addressing a bug exists in Bodhi, and is pushed to
updates-testing, the status automatically transitions to ON_QA
6) When the update is pushed to stable, Bodhi optionally closes the
bug automatically. If the update does not auto-close the bug, it
transitions to NEEDINFO_REPORTER, with a comment explaining that the
update has been pushed to stable, and to update and test in the new
release.

Note that at any step of the above process, the maintainer can "fast
track" the bug, and change it to ASSIGNED. The triage team is not
going to look at bugs that are not in NEW or NEEDINFO state. On the
flip side of that, it is not a maintainer's responsibility to look at
bugs that are in NEW any longer. They can focus their energy on the
bugs that are ASSIGNED to them.

Also, maintainers should not be allowed to set priority on bugs.
Setting severity is fine. Only QA or releng should set priorities.
This allows us to look at things in a sane manner (which is impossible
now since severity and priority fields come from /dev/urandom
seemingly), and possibly lessen the reliance on blocker bugs (though
blockers are useful in their own right, so don't think that we are
going to eliminate them any time soon).

It was also decided that when a bug is in NEEDINFO for one month, it
will be closed. Maintainers would need to realize that putting a bug
in NEEDINFO is putting it on the fast track for closure.

I think that's all that I have to say on this topic right now, let me
know if I'm missing anything or this is complete hogwash



Sounds like an excellent plan to me, lets implement this asap!

I would like to point out though that this solves only part of the problem. An
important part, but I wonder if anything was discussed regarding the other
part, unresponsive maintainers. I often see perfectly fine bugs (well
described, reproducable) with 0 maintainer attention. I know we are all human
but most of the time it are always the same maintainers who are unresponsive,
and they seem to simply be unresponsive to any bugs. So its not that they are
prioritizing, they seem to be simply ignoring bugzilla mail.


I know we have the awol procedure for this, but often they are not awol, they
are productive contributers, who's strengths lay outside of bugfixing.


Thus I would like to see a bug fixing team, to complement the bug triage team
who's task it will be to actually fix bugs which have moved to the assigned state.


Now primarily this is the task of the maintainer, but sometimes leaving this up
to the maintainer seems to not work one way or the other. So I guess it would
be good to have a fallback bugfixing team, and maybe a way for packagers, who
for example lack the coding skills, to subscribe to this team's services. As
always I'll put my code where my mouth is and I will gladly join such a team if
formed.


Regards,

Hans

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-15-2008, 09:12 AM
Rahul Sundaram
 
Default Fedora bug triage - workflow proposal

Patrice Dumas wrote:

On Mon, Jan 14, 2008 at 11:46:36PM -0500, Jon Stanley wrote:

It was also decided that when a bug is in NEEDINFO for one month, it
will be closed. Maintainers would need to realize that putting a bug
in NEEDINFO is putting it on the fast track for closure.


So what is the equivalent of NEEDINFO that doesn't put the bug on tracks
for closing?


Can you explain why you need that? That information would be useful to
determine a good workflow.


Rahul

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-15-2008, 09:12 AM
Patrice Dumas
 
Default Fedora bug triage - workflow proposal

On Tue, Jan 15, 2008 at 03:42:09PM +0530, Rahul Sundaram wrote:
> Patrice Dumas wrote:
>> On Mon, Jan 14, 2008 at 11:46:36PM -0500, Jon Stanley wrote:
>>> It was also decided that when a bug is in NEEDINFO for one month, it
>>> will be closed. Maintainers would need to realize that putting a bug
>>> in NEEDINFO is putting it on the fast track for closure.
>>
>> So what is the equivalent of NEEDINFO that doesn't put the bug on tracks
>> for closing?
>
> Can you explain why you need that? That information would be useful to
> determine a good workflow.

When I have a look at a number of bugs (for example my bugs) it allows
for me to know which ones I don't have to care about since they are in
wait for somebody to move.

--
Pat

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-15-2008, 09:15 AM
Patrice Dumas
 
Default Fedora bug triage - workflow proposal

On Tue, Jan 15, 2008 at 10:06:56AM +0100, Hans de Goede wrote:
>>
>
> Sounds like an excellent plan to me, lets implement this asap!
>
> I would like to point out though that this solves only part of the problem.
> An important part, but I wonder if anything was discussed regarding the
> other part, unresponsive maintainers. I often see perfectly fine bugs (well
> described, reproducable) with 0 maintainer attention. I know we are all

Even worse, there are trivial packaging changes needed as part of new
guidelines, for example, that are not fixed after months, even with
(trivial) patches attached.

I don't know what should be done for that, but this is a bit irritating.

--
Pat

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-15-2008, 09:56 AM
Till Maas
 
Default Fedora bug triage - workflow proposal

On Tue January 15 2008, Jon Stanley wrote:

> 4) Once a developer has taken responsibility for a bug and is
> actively working on it, the state transitions to ON_DEV.

This status is not mentioned in [1], will this be changed when this workflow
is accepted?

> Note that at any step of the above process, the maintainer can "fast
> track" the bug, and change it to ASSIGNED. The triage team is not
> going to look at bugs that are not in NEW or NEEDINFO state. On the
> flip side of that, it is not a maintainer's responsibility to look at
> bugs that are in NEW any longer. They can focus their energy on the
> bugs that are ASSIGNED to them.

I guess the triage team should also look at REOPENED bugs, e.g. when they
where closed because of lack from NEEDINFO.

> It was also decided that when a bug is in NEEDINFO for one month, it
> will be closed. Maintainers would need to realize that putting a bug
> in NEEDINFO is putting it on the fast track for closure.

It should be distinguished, from who information is required. E.g. when it is
not NEEDINFO_REPORTER, closing it after one month would not help.

> I think that's all that I have to say on this topic right now, let me
> know if I'm missing anything or this is complete hogwash

I like this workflow.

Regards,
Till


[1] https://bugzilla.redhat.com/page.cgi?id=bug_status.html#verified


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-15-2008, 10:25 AM
Ralf Corsepius
 
Default Fedora bug triage - workflow proposal

On Mon, 2008-01-14 at 23:46 -0500, Jon Stanley wrote:
> 2) Triage team looks at bug report, determines if dupe or
> insufficient information exists to solve it. If there is not enough
> information in the bug, then triage team puts the bug in NEEDINFO. As
> you will see below, this state has a finite life cycle associated with
> it.
I am having doubts the bug triage team will be able to judge on whether
a PR is legitimate or not but on trivial cases.

I.e. I would expect them to end up spam essentially filtering.

> 3) Assuming bug survives through the triage team, it changes state to
> ASSIGNED

To whom?

IMO, the real problem is getting a competent volunteer involved who is
likely sufficiently knowledgeable about a particular issue. i.e. to
communicate such issues, such that a volunteer can take action when _he_
wants.

That said, I consider lack of communication and "bug arbitration" to be
the actual flaw behind current bug tracking workflow in Fedora.

Ralf


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-15-2008, 10:58 AM
Simon Andrews
 
Default Fedora bug triage - workflow proposal

Jon Stanley wrote:


It was also decided that when a bug is in NEEDINFO for one month, it
will be closed. Maintainers would need to realize that putting a bug
in NEEDINFO is putting it on the fast track for closure.


If you're going to do this can someone please check that:

https://bugzilla.redhat.com/show_bug.cgi?id=219267

..has been fixed. I've had a couple of bugs which languished in
NEEDINFO for far too long because adding an attachment didn't reset them
to assigned.


Simon.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-15-2008, 12:37 PM
Rahul Sundaram
 
Default Fedora bug triage - workflow proposal

Jon Stanley wrote:


1) Reporter files a bug report, it originates in NEW state


Can we renamed this state to UNCONFIRMED?


2) Triage team looks at bug report, determines if dupe or
insufficient information exists to solve it. If there is not enough
information in the bug, then triage team puts the bug in NEEDINFO. As
you will see below, this state has a finite life cycle associated with
it.
3) Assuming bug survives through the triage team, it changes state to
ASSIGNED (triage team can put it in either NEEDINFO or CLOSED, as
appropriate). Note that per the definition[1], ASSIGNED does not mean
that someone has actually agreed to take action, simply that the issue
is well defined and triaged accordingly


Wouldn't a state like TRIAGED be more meaningful then? ASSIGNED
frequently is assumed to be assuming ownership by the maintainers.



4) Once a developer has taken responsibility for a bug and is
actively working on it, the state transitions to ON_DEV.


If ASSIGNED is renamed to TRIAGED, then this state can be known as
ASSIGNED instead.



Setting severity is fine. Only QA or releng should set priorities.
This allows us to look at things in a sane manner (which is impossible
now since severity and priority fields come from /dev/urandom
seemingly), and possibly lessen the reliance on blocker bugs (though
blockers are useful in their own right, so don't think that we are
going to eliminate them any time soon).


I believe bugzilla folks are recommending the usage of flags over
blocker bugs.



It was also decided that when a bug is in NEEDINFO for one month, it
will be closed. Maintainers would need to realize that putting a bug
in NEEDINFO is putting it on the fast track for closure.


Would a stock message be send to the bug reporters when closing bugs?

Would a separate Fedora page in bugzilla.redhat.com be useful?

Rahul

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 12:04 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org