Fwd: closing out old bugs of unmaintained releases

[Jon Stanley]

As part of a re-launch of the bug triage project [1,2], I believe that
it would be beneficial to mass close the bugs that are for releases
that are no longer maintained.  Please find my proposal for this
below.  Sorry for cross-posting, but it's relevant across multiple
communities within Fedora.

I will be at FUDCon in order to discuss the very topic of the
re-launch of the triage project.

[1] https://www.redhat.com/archives/fedora-advisory-board/2008-January/msg000...
[2] https://www.redhat.com/archives/fedora-marketing-list/2008-January/msg000...

---------- Forwarded message ----------
From: Jon Stanley <jonstanley(a)gmail.com&gt;
Date: Jan 4, 2008 1:45 PM
Subject: closing out old bugs of unmaintained releases
To: fedora-advisory-board(a)redhat.com


I can put some time this weekend into closing out old bugs, however,
before doing so, I wanted to make sure that our messaging is crystal
clear.  What I had been doing for kernel bugs is placing them in
NEEDINFO_REPORTER and asking if the problem still existed, etc after
manually reviewing the bugs (some I changed to a current release
because it was mentioned in comments, but not in the version
metadata).  However, this won't scale - there's no way that I or
anybody else can reasonably review 3600 bugs for ones that are
incorrectly tagged.  This leaves us with ~9000 bugs (F7, F8, and
rawhide) to deal with (still a monumental task).  I propose doing
something similar with rawhide bugs that haven't been touched in ~6
months, not sure of the number of those, haven't looked yet.  Here's
the proposed comment to WONTFIX these.  I want to get the most input
possible before doing this:

<begin>
Hello,

Thank you for taking the time to report this bug.  Unfortunately, this
version of Fedora has reach end-of-life and is no longer maintained.
Please refer to  http://fedoraproject.org/wiki/LifeCycle for an
explanation of the Fedora lifecycle policy.

We therefore regret the necessity of closing this bug report WONTFIX.
Please upgrade to a currently maintained release of Fedora, currently
either Fedora 7 or Fedora 8, and attempt to reproduce this bug.  If
the bug still exists, feel free to re-open this bug report, changing
the version accordingly, or file a new bug report (you can use the
'Clone as Bug' link at the top of this bug report in order to preserve
the content of this bug in the new one).

We regret any inconvenience that this may cause you, and thank you for
your continued support of Fedora!
<end>

I propose starting with FC6, since that recently reached EOL and
people would be understanding about it (hopefully).
Comments/thoughts/suggestions/flames welcome.



-- 
Jon Stanley
Fedora Ambassador
jstanley(a)fedoraproject.org

[Kevin Fenzi]

On Fri, 4 Jan 2008 15:11:51 -0500
jonstanley(a)gmail.com ("Jon Stanley") wrote:

>  As part of a re-launch of the bug triage project [1,2], I believe
> that
>  it would be beneficial to mass close the bugs that are for releases
>  that are no longer maintained.  Please find my proposal for this
>  below.  Sorry for cross-posting, but it's relevant across multiple
>  communities within Fedora. 
Do we really want to just close all those bugs? 

>  I will be at FUDCon in order to discuss the very topic of the
>  re-launch of the triage project. 
Excellent. I think we need to address this issue... 

>  [1]
>  https://www.redhat.com/archives/fedora-advisory-board/2008-January/msg000...
>  [2]
>  https://www.redhat.com/archives/fedora-marketing-list/2008-January/msg000...
>  
>  ---------- Forwarded message ----------
>  From: Jon Stanley <jonstanley(a)gmail.com&gt;
>  Date: Jan 4, 2008 1:45 PM
>  Subject: closing out old bugs of unmaintained releases
>  To: fedora-advisory-board(a)redhat.com
>  
>  
>  I can put some time this weekend into closing out old bugs, however, 
Note that you might want to wait until after fudcon and until you have
gotten input from everyone before doing anything hasty... 

>  before doing so, I wanted to make sure that our messaging is crystal
>  clear.  What I had been doing for kernel bugs is placing them in
>  NEEDINFO_REPORTER and asking if the problem still existed, etc after
>  manually reviewing the bugs (some I changed to a current release
>  because it was mentioned in comments, but not in the version
>  metadata).  However, this won't scale - there's no way that I or
>  anybody else can reasonably review 3600 bugs for ones that are
>  incorrectly tagged.   
Sure, agreed 100%, but closing them makes less work for us, but makes
anyone who filed them in the past where they were ignored pretty mad. 

See: http://www.jwz.org/doc/cadt.html

How about instead we move them all up to a current release... 
Then, the maintainer should ping them or deal with them in some way. 

I'm concerned that these sort of mass closings or "clear the deck" just
ends up annoying bug submitters, and doesn't really help us in the long
term since it just happens again a few releases down the road... 
so all kinds of bugs get filed, ignored, then closed, even when they
still do affect current releases. 

>  This leaves us with ~9000 bugs (F7, F8, and
>  rawhide) to deal with (still a monumental task).  I propose doing
>  something similar with rawhide bugs that haven't been touched in ~6
>  months, not sure of the number of those, haven't looked yet.  Here's
>  the proposed comment to WONTFIX these.  I want to get the most input
>  possible before doing this: 
Yeah, but how many of the now closed fc6 or rawhide bugs are really
still bugs? we have no idea... we should deal with the whole IMHO. 

>  <begin>
>  Hello,
>  
>  Thank you for taking the time to report this bug.  Unfortunately, this
>  version of Fedora has reach end-of-life and is no longer maintained.
>  Please refer to  http://fedoraproject.org/wiki/LifeCycle for an
>  explanation of the Fedora lifecycle policy.
>  
>  We therefore regret the necessity of closing this bug report WONTFIX.
>  Please upgrade to a currently maintained release of Fedora, currently
>  either Fedora 7 or Fedora 8, and attempt to reproduce this bug.  If
>  the bug still exists, feel free to re-open this bug report, changing
>  the version accordingly, or file a new bug report (you can use the
>  'Clone as Bug' link at the top of this bug report in order to preserve
>  the content of this bug in the new one).
>  
>  We regret any inconvenience that this may cause you, and thank you for
>  your continued support of Fedora!
>  <end>
>  
>  I propose starting with FC6, since that recently reached EOL and
>  people would be understanding about it (hopefully).
>  Comments/thoughts/suggestions/flames welcome. 
I agree we need to do something, but I don't think mass closing is the
answer. We need to get things to where maintainers do something with
their bugs, or in the cases of packages where maintainers can't
possibly handle things (kernel, rpm, glibc, whatever) we need to have
people helping those maintainers. 

I also don't think 'bug days' really help much, except as a way to
possibly teach people to triage bugs. The mass of bugs is just too
daunting and any single day is kind of a drop in the bucket. 

Perhaps one thing we could do is generate a report with packages with
the most bugs, to point out where we could focus our efforts? 
Or we could look at oldest bugs and try and bring those up to date.

Just some thoughts... 

kevin

[Andrew Farris]

Kevin Fenzi wrote:
>  Note that you might want to wait until after fudcon and until you
> have
>  gotten input from everyone before doing anything hasty...  
Probably a good idea to not be hasty on a large step like this, but the same 
problem has been around since FC1 (forever?).

> > before doing so, I wanted to make sure that our messaging is
> crystal
> > clear.  What I had been doing for kernel bugs is placing them in
> > NEEDINFO_REPORTER and asking if the problem still existed, etc after
> > manually reviewing the bugs (some I changed to a current release
> > because it was mentioned in comments, but not in the version
> > metadata).  However, this won't scale - there's no way that I or
> > anybody else can reasonably review 3600 bugs for ones that are
> > incorrectly tagged.  
>  
>  Sure, agreed 100%, but closing them makes less work for us, but makes
>  anyone who filed them in the past where they were ignored pretty mad. 
>  
>  See: http://www.jwz.org/doc/cadt.html 
He may have a point of interest there, but like it or not new code bases get 
released.  This is something the upstream project leads need to consider 
thoughtfully, not so much those working with the bugs later.

>  How about instead we move them all up to a current release... 
>  Then, the maintainer should ping them or deal with them in some way. 
>  
>  I'm concerned that these sort of mass closings or "clear the deck" just
>  ends up annoying bug submitters, and doesn't really help us in the long
>  term since it just happens again a few releases down the road... 
>  so all kinds of bugs get filed, ignored, then closed, even when they
>  still do affect current releases.  
Eeww, moving bugs across releases is a worse idea than mass closing frankly. 
The rate that major things change in fedora is too rapid to do this and hope 
that the bugs can be figured out... the second you try this you've got to go 
back and ask 'ok which version of xx and xx and xx and xx were installed' when 
thats not necessarily as important if you know the release. (think changes in 
gcc and glibc from release to release)

If you want to avoid bug reporter frustration then confusing the hell out of 
them is a bad idea too.  It is far simpler to ask bugs to be refiled or edited 
to indicate they still apply to new releases after the reporter figures out that 
they do.

Why cannot the bugs be left open and just simply filtered by non-EOL releases? 
This would feel a little bit less like your work as a bug reporter is being 
ignored (while it still is for those bugs).  The maintainers would be able to 
look at open old bugs if they know the code base is still shared, and easily 
filtered if its not.  But at the same time no matter what is done, those bug 
reporters should be upgrading and identifying if the bugs still exist in new 
releases, so something should be done to indicate to them that the old bugs are 
stale.

Would it be possible to choose a preset response for these bugs now, but not 
apply them in mass closing... then asking bug triage to close those bugs as 
quickly as possible where 1) the release is EOL, 2) the component has changed 
major versions from that EOL release to current.  Bugs that are for EOL releases 
but have similar component versions in new releases should be left open as they 
probably still apply.  I suspect closing those alone would have a big impact in 
the number of bugs still open.

-- 
Andrew Farris <lordmorgul(a)gmail.com&gt; <ajfarris(a)gmail.com&gt;
  gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----

[Jeff MacDonald]

On Fri, Jan 04, 2008 at 01:49:14PM -0800, Andrew Farris wrote:
>  Kevin Fenzi wrote:
>  >Note that you might want to wait until after fudcon and until you have
>  >gotten input from everyone before doing anything hasty... 
>  
>  Probably a good idea to not be hasty on a large step like this, but the 
>  same problem has been around since FC1 (forever?).
>   
yep.

I am +1 for adding an "EOL flag"

how about taking a page from the http://pear.php.net/ playbook and make some
stats so *everbody* (users, maintainers, etc) can see the "average number of
bugs" for a particular package. also stats like "10 open bugs, 8 closed, 2
that are EOL". the PEAR project has an irc bot that will alter /topic to
indicate the total number of bugs, but it is not necessary to go that far at
this point :)

hmm.. maybe a credit system where there would be a penalty for open and EOL
bugs vs. current ones.

regards,
 --jeff
-- 
http://zoidtechnologies.com/ -- websites that suck less

[Kevin Fenzi]

On Fri, 04 Jan 2008 13:49:14 -0800
lordmorgul(a)gmail.com (Andrew Farris) wrote:

>  Kevin Fenzi wrote:
>  > Note that you might want to wait until after fudcon and until you
>  > have gotten input from everyone before doing anything hasty... 
>  
>  Probably a good idea to not be hasty on a large step like this, but
>  the same problem has been around since FC1 (forever?). 
Yeah, indeed. But I think thats part of the problem.... We get
backloged and the first thought is to do something about the backlog,
but that doesn't really solve the problem, just keeps us in a cycle. 
I think we need to look at the entire problem and come up with a full
solution, or at least a full attempted solution. 

I think there are several problems here: 

1. There is a big backlog of bugs that aren't getting attention. 

2. There are more bugs flowing in than maintainers are dealing with,
which adds to the backlog over time. 

3. Some high profile packages have so many new bugs that there is no way
any single maintainer could handle them. 

4. There is no flow from/to upstream projects (or very little). I know
from my own Xfce bugs when something is a upstream issue, I usually
file the upstream bug, follow it and then close the fedora bug when
it's fixed upstream or a patch is available. Thats very very labor
intensive. 

I think most people are concentrating on the backlog issue to the
exclusion of all the other issues, and I think those need solutions
before doing anything to the backlog makes sense. 

For issue 2 above, perhaps if we have a triage team in place that tried
to triage all the incoming bugs as they were submitted it might assist
with issue 3 at least, as they could close dups, gather more info or
perhaps close bugs that were notabug/wontfix and save maintainer time. 
Packages like the kernel and rpm are going to need their own teams of
people. The upstream/downstream issue might be helped by things like
OpenID. 

For problems 2 and 3, refer to: 
http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus#head-181b0...
for maintainers with the most bugs. 

I don't have any wonderful answers, but I think we should look at the
entire picture here and come up with a way to address the inflow first,
and then look at the backlog as we are more able to keep up. 

>  > See: http://www.jwz.org/doc/cadt.html
>  
>  He may have a point of interest there, but like it or not new code
>  bases get released.  This is something the upstream project leads
>  need to consider thoughtfully, not so much those working with the
>  bugs later. 
Sure it is... If the bug is reproducable, can't you check and see if it
still happens in the new version? Or if not get the reporter to try? 
Or if the new version doesn't have that functionality, close the issue,
or the like... 

>  Eeww, moving bugs across releases is a worse idea than mass closing
>  frankly. The rate that major things change in fedora is too rapid to
>  do this and hope that the bugs can be figured out... the second you
>  try this you've got to go back and ask 'ok which version of xx and xx
>  and xx and xx were installed' when thats not necessarily as important
>  if you know the release. (think changes in gcc and glibc from release
>  to release) 
Sure, but if the reporter doesn't respond, or the maintainer can't
reproduce on the current release, then they can close it... instead of
forcing the submitter to re-open it. A lot of people will just not want
to deal with the hassle. 

>  If you want to avoid bug reporter frustration then confusing the
> hell
>  out of them is a bad idea too.  It is far simpler to ask bugs to be
>  refiled or edited to indicate they still apply to new releases after
>  the reporter figures out that they do. 
If it's easy for them to do so. 

>  Why cannot the bugs be left open and just simply filtered by non-EOL
>  releases? This would feel a little bit less like your work as a bug
>  reporter is being ignored (while it still is for those bugs).  The
>  maintainers would be able to look at open old bugs if they know the
>  code base is still shared, and easily filtered if its not.  But at
>  the same time no matter what is done, those bug reporters should be
>  upgrading and identifying if the bugs still exist in new releases, so
>  something should be done to indicate to them that the old bugs are
>  stale. 
Thats no good in my opinion, because then the bugs would be ignored.
You might as well close them and tell the submitter for sure the bug
isn't going to be dealt with. 

>  Would it be possible to choose a preset response for these bugs now,
>  but not apply them in mass closing... then asking bug triage to close
>  those bugs as quickly as possible where 1) the release is EOL, 2) the
>  component has changed major versions from that EOL release to
>  current.  Bugs that are for EOL releases but have similar component
>  versions in new releases should be left open as they probably still
>  apply.  I suspect closing those alone would have a big impact in the
>  number of bugs still open. 
Perhaps. 

kevin

[Jon Stanley]

On Jan 4, 2008 7:10 PM, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:

>  Yeah, indeed. But I think thats part of the problem.... We get
>  backloged and the first thought is to do something about the backlog, 
The backlog that would be eliminated by this action is about 1/3 of
the currently open Fedora bugs.

>  but that doesn't really solve the problem, just keeps us in a
> cycle.
>  I think we need to look at the entire problem and come up with a full
>  solution, or at least a full attempted solution. 
This is why I'm going to FUDCon, to come up with  a solution with the
maximum amount of community input.  I encourage anyone coming to
FUDCon that has an opinion on this topic to show up and provide their
input  - without community input and buy-in, there's no way that I can
be successful in this effort.

>  I think there are several problems here:
>
>  1. There is a big backlog of bugs that aren't getting attention. 
That's why it's necessary to "clear the deck".  To give some current
stats:

FC1-FC6 have 3,811 in any status other than CLOSED [1]
F7 has 2073 bugs open [2]
F8 has 2066 bugs open [3]
rawhide has 5638 bugs currently open [4]

I'm looking for a way to search rawhide bugs that have not been
changed since 2007-06-01, however that seems to be a bit of a tall
order with the current bugziila interface - however I have a hunch
that the number is probably about half of the open ones.

>  2. There are more bugs flowing in than maintainers are dealing with,
>  which adds to the backlog over time. 
That's where the triage team comes in, putting sane priorities on
things and managing maintainer workload.  Again, this is all part of
the grand effort to *build* a triage team.

>  3. Some high profile packages have so many new bugs that there is no
> way
>  any single maintainer could handle them. 
See 2.  The number of actual, unique, high-priority bugs that come in
against these packages I assume is perfectly manageable.  Also, keep
in mind that high-profile packages generally have a team of
maintainers working on them, especially the ones that we are upstream
for.

>  4. There is no flow from/to upstream projects (or very little). I
> know
>  from my own Xfce bugs when something is a upstream issue, I usually
>  file the upstream bug, follow it and then close the fedora bug when
>  it's fixed upstream or a patch is available. Thats very very labor
>  intensive. 
There's nothing that says a maintainer has to do this.  A triager can
equally well file an upstream bug - the thing is, I think at that
point, it's the responsibility of the reporter to follow the upstream
bug.  I also think that UPSTREAM should not be a closing status - it
should be rather 'this is on hold while we're waiting for upstream to
do something about it, come back once they do and the Fedora
maintainer can make a decision to incorporate or not'

>  I think most people are concentrating on the backlog issue to the
>  exclusion of all the other issues, and I think those need solutions
>  before doing anything to the backlog makes sense. 
+4000

>  For problems 2 and 3, refer to:
>
> http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus#head-181b0...
>  for maintainers with the most bugs. 
Didn't know this existed, thanks!

>  Sure, but if the reporter doesn't respond, or the maintainer
> can't
>  reproduce on the current release, then they can close it... instead of
>  forcing the submitter to re-open it. A lot of people will just not want
>  to deal with the hassle. 
How about finding a common ground?  Placing them in NEEDINFO_REPORTER
for a week and then auto-close those that are still in that state?

>  If it's easy for them to do so. 
It's trivial.  That's why I mentioned the 'clone as bug' feature of
bugzilla.  My guess is that some (a lot?) of the people who would
reopen a bug are not the assignee or reporter (or a triager), and thus
would not have the proper bugzilla permissions to re-open.  That's
where the clone comes in.

>  Thats no good in my opinion, because then the bugs would be ignored.
>  You might as well close them and tell the submitter for sure the bug
>  isn't going to be dealt with. 
+20,000

[1]
https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamed&namedcmd=unm...
[2]
https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamed&namedcmd=F7-...
[3]
https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamed&namedcmd=F8-...
[4]
https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamed&namedcmd=raw...

[Till Maas]

On Sat January 5 2008, Jon Stanley wrote:

>  How about finding a common ground?  Placing them in
> NEEDINFO_REPORTER
>  for a week and then auto-close those that are still in that state? 
Another idea I have would be to treat bugs depending on the count of open bugs 
tor the component/package. E.g. there are a lot of bugs for F6 and previous 
for some packages (e.g. kernel, anaconda) that also have a lot of open bug 
reports for F7 and later. Here it is very unlikely, that the bug will be 
fixed soon or it is likely, that the bug is already fixed but nobody 
mentioned it / closed the bug. For kernel and anaconda, I guess testing 
whether the bug is still present, needs often special hardware or a special 
setup. Therefore just using needinfo and closing after a timeout may be not 
so bad. Unless we can find the ressources to fix the bugs. Maybe this allows 
to reduce the amount of open bugs to a smaller number, that allows to review 
them manually by a team to find out, whether they are already fixed and 
adjust the version.

Also there are 1308 Bugs for F6 and earlier already in NEEDINFO state. Here 
closing all bugs that are in this state for, e.g. 3 months or longer, also 
sounds not so bad to me.

Regards,
Till

[Andrew Farris]

Jon Stanley wrote:
>  On Jan 4, 2008 7:10 PM, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  
> > Yeah, indeed. But I think thats part of the problem.... We get
> > backloged and the first thought is to do something about the backlog,
>  
>  The backlog that would be eliminated by this action is about 1/3 of
>  the currently open Fedora bugs.
>  
> > but that doesn't really solve the problem, just keeps us in a cycle.
> > I think we need to look at the entire problem and come up with a full
> > solution, or at least a full attempted solution.
>  
>  This is why I'm going to FUDCon, to come up with  a solution with the
>  maximum amount of community input.  I encourage anyone coming to
>  FUDCon that has an opinion on this topic to show up and provide their
>  input  - without community input and buy-in, there's no way that I can
>  be successful in this effort.
>  
> > I think there are several problems here:
> >
> > 1. There is a big backlog of bugs that aren't getting attention.
>  
>  That's why it's necessary to "clear the deck".  To give some current
> stats:
>  
>  FC1-FC6 have 3,811 in any status other than CLOSED [1]
>  F7 has 2073 bugs open [2]
>  F8 has 2066 bugs open [3]
>  rawhide has 5638 bugs currently open [4]
>  
>  I'm looking for a way to search rawhide bugs that have not been
>  changed since 2007-06-01, however that seems to be a bit of a tall
>  order with the current bugziila interface - however I have a hunch
>  that the number is probably about half of the open ones. 
The interesting thing here is that MANY of those rawhide bugs are in fact not 
for current rawhide, and that because there is a lack of rawhide versioning 
there are many of them that should be closed WONTFIX as well.  I had one open 
bug myself that had been filed as rawhide but not updated since 2004 (I remedied 
that due to this thread).

I would say that the recent change to rawhide tag rather than devel should have 
been more thorough and included a rawhide version (pre-F9) for instance. 
Getting rid of the 3 different -testX versions was good, but rawhide changes and 
bugs filed against it get left behind.

-- 
Andrew Farris <lordmorgul(a)gmail.com&gt; <ajfarris(a)gmail.com&gt;
  gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----

[John Poelstra]

Andrew Farris said the following on 01/05/2008 04:42 PM Pacific Time:
>  
>  The interesting thing here is that MANY of those rawhide bugs are in 
>  fact not for current rawhide, and that because there is a lack of 
>  rawhide versioning there are many of them that should be closed WONTFIX 
>  as well.  I had one open bug myself that had been filed as rawhide but 
>  not updated since 2004 (I remedied that due to this thread). 
Yes, this should be part of the clean-up proposal--closing rawhide bugs 
before a certain date.

>  I would say that the recent change to rawhide tag rather than devel 
>  should have been more thorough and included a rawhide version (pre-F9) 
>  for instance. Getting rid of the 3 different -testX versions was good, 
>  but rawhide changes and bugs filed against it get left behind.
>   
It was discussed on fedora-test-list at the time of the change of the 
bugzilla versions.

Most seemed to be in agreement that going forward, at the GA of each new 
release, the version of all existing rawhide bugs would be mass changed 
to the GA version.  For example, for the upcoming release, open rawhide 
bugs at the time of GA we would changed to Fedora 9.  This would have a 
few benefits as we go forward for each release:
   1) encourage the closing of rawhide bugs that qualify
   2) anchor the remaining rawhide bugs to the closest GA release so 
there is a marker in the future as to when they were reported.

John

[Andrew Farris]

John Poelstra wrote:
> > I would say that the recent change to rawhide tag rather than
> devel 
> > should have been more thorough and included a rawhide version (pre-F9) 
> > for instance. Getting rid of the 3 different -testX versions was good, 
> > but rawhide changes and bugs filed against it get left behind.
> >
>  
>  It was discussed on fedora-test-list at the time of the change of the 
>  bugzilla versions.
>  
>  Most seemed to be in agreement that going forward, at the GA of each new 
>  release, the version of all existing rawhide bugs would be mass changed 
>  to the GA version.  For example, for the upcoming release, open rawhide 
>  bugs at the time of GA we would changed to Fedora 9.  This would have a 
>  few benefits as we go forward for each release:
>    1) encourage the closing of rawhide bugs that qualify
>    2) anchor the remaining rawhide bugs to the closest GA release so 
>  there is a marker in the future as to when they were reported.
>  
>  John
>   
I guess I missed that discussion but that would indeed fix the problem of 
carrying Rawhide bugs along into next release.

-- 
Andrew Farris <lordmorgul(a)gmail.com&gt; <ajfarris(a)gmail.com&gt;
  gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----

[Bill Nottingham]

John Poelstra (poelstra(a)redhat.com) said: 
>  Most seemed to be in agreement that going forward, at the GA of each
> new 
>  release, the version of all existing rawhide bugs would be mass changed to 
>  the GA version.  For example, for the upcoming release, open rawhide bugs 
>  at the time of GA we would changed to Fedora 9.  This would have a few 
>  benefits as we go forward for each release:
>    1) encourage the closing of rawhide bugs that qualify
>    2) anchor the remaining rawhide bugs to the closest GA release so there 
>  is a marker in the future as to when they were reported. 
Hm, this runs afoul of things like hosted projects that use Fedora bugzilla
as essentially an upstream bug tracker.

Bill

[Daniel P. Berrange]

On Tue, Jan 08, 2008 at 05:15:57PM -0500, Bill Nottingham wrote:
>  John Poelstra (poelstra(a)redhat.com) said: 
>  > Most seemed to be in agreement that going forward, at the GA of each new 
>  > release, the version of all existing rawhide bugs would be mass changed to 
>  > the GA version.  For example, for the upcoming release, open rawhide bugs 
>  > at the time of GA we would changed to Fedora 9.  This would have a few 
>  > benefits as we go forward for each release:
>  >   1) encourage the closing of rawhide bugs that qualify
>  >   2) anchor the remaining rawhide bugs to the closest GA release so there 
>  > is a marker in the future as to when they were reported.
>  
>  Hm, this runs afoul of things like hosted projects that use Fedora bugzilla
>  as essentially an upstream bug tracker. 
Shouldn't they be using a 'Fedora hosted' product, rather than the
main 'Fedora' product (albeit with possibly the same 'component' value)

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Jesse Keating]

On Tue, 8 Jan 2008 22:18:09 +0000
"Daniel P. Berrange" <berrange(a)redhat.com&gt; wrote:

>  Shouldn't they be using a 'Fedora hosted' product, rather
> than the
>  main 'Fedora' product (albeit with possibly the same 'component'
>  value) 
That product was a mistake on my part.  It's unwieldy to use products
like this, we'd have to create products for each hosted project, and
that just gets noisy.

This was also pre-Trac.  Mock just hasn't been persuaded to move to
Trac for upstream bug tracking.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?

[Christopher Brown]

Over the previous few days * wrote:

<snip>

Sorry I'm a bit late to the party but thought I'd throw my comments
after having spent the past few months trawling through every F7
kernel bug[1]. Specifically in relation to F6 bugs, I think that
closing out bugs with the EOL message is A Very Good Thing for the
following reasons:

- Closing bugs for a legitimate reason often gives them a shot in the
arm. Yes, there will be a few people who get upset at this but I
_firmly_ believe this is fewer than many fear.
- A huge number of responses after prodding sleeping bugs have been
"Oh, yeah, I upgraded to F7 and this was fixed. Forgot to update bug,
please close."
- F6 is EOL - we do not support it and people know (or should know) this
- Reporter can re-open with updated info if necessary

In response to the wider question of bug triaging, I find it extremely
rewarding work [2] (though there are some bad days [3]) and as Jesse
suggested [4] I would be happy to assist in the triaging effort. Chris
Aillon [5] even suggested paying someone to do it so I officially
apply for the position, providing my previous triaging work as my CV.
:)

Which works well btw as I'm currently jobseeking [6]....

[1] https://www.redhat.com/archives/fedora-kernel-list/2007-September/msg0002...
[2] https://bugzilla.redhat.com/show_bug.cgi?id=297091
 [3] https://bugzilla.redhat.com/show_bug.cgi?id=260101
[4] https://www.redhat.com/archives/fedora-advisory-board/2008-January/msg000...
[5] https://www.redhat.com/archives/fedora-advisory-board/2008-January/msg000...
[6] http://www.chruz.com/about/

Cheers
-- 
Christopher Brown

http://www.chruz.com

[Michael E Brown]

On Tue, Jan 08, 2008 at 05:26:10PM -0500, Jesse Keating wrote:
>  On Tue, 8 Jan 2008 22:18:09 +0000
>  "Daniel P. Berrange" <berrange(a)redhat.com&gt; wrote:
>  
>  > Shouldn't they be using a 'Fedora hosted' product, rather than the
>  > main 'Fedora' product (albeit with possibly the same 'component'
>  > value)
>  
>  That product was a mistake on my part.  It's unwieldy to use products
>  like this, we'd have to create products for each hosted project, and
>  that just gets noisy.
>  
>  This was also pre-Trac.  Mock just hasn't been persuaded to move to
>  Trac for upstream bug tracking. 
Benefits of Trac? It seems the case now that most mock users expect to
just enter bugs in bugzilla.
--
Michael

[Jesse Keating]

On Tue, 8 Jan 2008 23:50:38 -0600
Michael E Brown <Michael_E_Brown(a)dell.com&gt; wrote:

>  Benefits of Trac? It seems the case now that most mock users expect
> to
>  just enter bugs in bugzilla. 
The only real benefit is to separate bugs in Fedora versions from bugs
in development, or long term tickets for changing things etc..  But
it's totally not necessary.  In fact, I think we can just do away with
the Fedora Hosted Projects product in bugzilla and have all mock bugs
just get filed as bugs in a fedora / epel release.  The only issue with
that is if any other distros start using mock, and forcing them to file
Fedora bugs for their mock doesn't seem right.  But meh.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?

[Jon Stanley]

On Jan 8, 2008 5:15 PM, Bill Nottingham <notting(a)redhat.com&gt; wrote:

>  Hm, this runs afoul of things like hosted projects that use Fedora
> bugzilla
>  as essentially an upstream bug tracker. 
IIRC, there is both a 'Fedora Hosted' product, or individual trac
instances.  I think the trac instances are the current method of
dealing with this.

[Bill Nottingham]

Jon Stanley (jonstanley(a)gmail.com) said: 
>  On Jan 8, 2008 5:15 PM, Bill Nottingham <notting(a)redhat.com&gt;
> wrote:
>  
>  > Hm, this runs afoul of things like hosted projects that use Fedora bugzilla
>  > as essentially an upstream bug tracker.
>  
>  IIRC, there is both a 'Fedora Hosted' product, or individual trac
>  instances.  I think the trac instances are the current method of
>  dealing with this. 
And if the upstream maintainer runs screaming at the idea of using trac
for bug tracking?

(Note: most of these projects (anaconda, etc.) predate both hosted and trac.)

Bill

[Jesse Keating]

On Tue, 8 Jan 2008 17:44:50 -0500
Bill Nottingham <notting(a)redhat.com&gt; wrote:

>  And if the upstream maintainer runs screaming at the idea of using
>  trac for bug tracking?
>  
>  (Note: most of these projects (anaconda, etc.) predate both hosted
>  and trac.) 

Those projects are likely a lot more tied to the Fedora release anyway,
and it makes some sense to treat the bugs filed against them the same
as bugs filed against the Fedora version of them.  (whoh, meta)

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?

[Jon Stanley]

On Jan 4, 2008 4:07 PM, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:

>  See: http://www.jwz.org/doc/cadt.html 
See http://jwz.livejournal.com/154529.html where the original author comments:

"There may not be an immediate practical difference to the user, but
the attitude behind it matters: maybe the developer thinks it's ok to
just ignore old bugs: that's often true, and that's really bad. But
then, maybe the developer doesn't think that, but instead, the project
is just totally floundering: that's also often true, and easier to
forgive. In the latter case, at least they'll be trying to fix the
problem; in the former case, they don't think there is a problem."

We are obviously in the latter situation here.  We *are* attempting to
fix this (at least I know that I am).

[Till Maas]

On Fr Januar 4 2008, Jon Stanley wrote:

>  I can put some time this weekend into closing out old bugs, however,
>  before doing so, I wanted to make sure that our messaging is crystal
>  clear.  What I had been doing for kernel bugs is placing them in
>  NEEDINFO_REPORTER and asking if the problem still existed, etc after
>  manually reviewing the bugs (some I changed to a current release
>  because it was mentioned in comments, but not in the version
>  metadata).  However, this won't scale - there's no way that I or
>  anybody else can reasonably review 3600 bugs for ones that are
>  incorrectly tagged.  This leaves us with ~9000 bugs (F7, F8, and
>  rawhide) to deal with (still a monumental task).  I propose doing
>  something similar with rawhide bugs that haven't been touched in ~6
>  months, not sure of the number of those, haven't looked yet.  Here's
>  the proposed comment to WONTFIX these.  I want to get the most input
>  possible before doing this: 
I would like it more when first every bug gets marked NEEDINFO_REPORTER and 
ask him whether or not the problem still exists and in case it does, to 
adjust the version of the Bug report or close it with e.g. currentrelease. In 
case the reporter did not respond within two weeks, ping him via bugzilla and 
then another two weeks later, close the bug with WONTFIX or INSUFFICANT_DATA. 
This is at least a little better bug reporter experience. This is more or less 
what I did when I started to comaintain some packages, that had several bugs 
and the maintainers too little time.

Regards,
Till

[Michael Schwendt]

On Sat, 05 Jan 2008 13:28:07 +0100, Till Maas wrote:

>  I would like it more when first every bug gets marked
> NEEDINFO_REPORTER and 
>  ask him whether or not the problem still exists and in case it does, to 
>  adjust the version of the Bug report or close it with e.g. currentrelease. In 
>  case the reporter did not respond within two weeks, ping him via bugzilla and 
>  then another two weeks later, close the bug with WONTFIX or INSUFFICANT_DATA. 
>  This is at least a little better bug reporter experience. 
Better? I doubt that. Many a bug reporter will be annoyed when after
months or a year of ignoring a ticket and not fixing the bug somebody
comes along and puts pressure on the reporter to allocate time for
retesting. It is even more rude to close such old bugs as WONTFIX or
INSUFFICIENT_DATA. When only after the EOL of a distribution version there
is activity within a ticket, that is like saying "we didn't care about
your bug report this time, and we don't promise either that we look into
the issue this time". Actually a reporter expects a package maintainer to
evaluate a new report ASAP and make use of NEEDINFO states ASAP, so
_sufficient data_ could be provided while the issue is _hot_. The packager
ought to tell whether the provided data are insufficient and whether the
problem is reproducible. When however it takes too long for the packager
to handle a bug report, that increases the risk that the reporter moves on
with different sofware/release or abandoning to use the software that
causes trouble.

>  This is more or less 
>  what I did when I started to comaintain some packages, that had several bugs 
>  and the maintainers too little time. 
Please don't forget that bug reporters have limited time only, too.

Bug triagers should focus on filling a queue with tickets, where package
maintainers commit to taking a serious look at those tickets. The NEEDINFO
state should be used when there is committment to moving forward with a
ticket, not just to give the reporter something to do after a long of no
interest in the report.

[Jon Stanley]

On Jan 5, 2008 11:47 AM, Michael Schwendt
<mschwendt.tmp0701.nospam(a)arcor.de&gt; wrote:

>  Better? I doubt that. Many a bug reporter will be annoyed when after
>  months or a year of ignoring a ticket and not fixing the bug somebody
>  comes along and puts pressure on the reporter to allocate time for
>  retesting. 
That exact phenomenon  is what led me down this road (not this
particular course of action, but the realization that something had to
be done). [1].  I was bound and determined to end that cycle, and have
more instances like [2].

>  t is even more rude to close such old bugs as WONTFIX or
>  INSUFFICIENT_DATA. When only after the EOL of a distribution version there
>  is activity within a ticket, that is like saying "we didn't care about
>  your bug report this time, and we don't promise either that we look into
>  the issue this time". 
Is there some other reasonable course of action?  I'm sure that there
will be people with that perception, but I'm not sure what to do about
it.  I'm remembering back to my high school days now, when a teacher
used to tell me (and attributed it to someone else, but I can't for
the life of me remember who) "you can please some of the people all
the time, you can please all of the people some of the time, but you
can't please all the people all the time".

>  Actually a reporter expects a package maintainer to
>  evaluate a new report ASAP and make use of NEEDINFO states ASAP, so
>  _sufficient data_ could be provided while the issue is _hot_. The packager
>  ought to tell whether the provided data are insufficient and whether the
>  problem is reproducible. 
Either that or a triager to do the same.  People do not expect their
bugs to be magically fixed (some do, but those people are unreasonable
IM[NS]HO).  What they expect is someone to say "yes, we have received
this report.  Your voice is heard.  Maybe I'll poke a developer about
this".  Part of the job of a good triage team is maintainer/developer
interaction.

>  When however it takes too long for the packager
>  to handle a bug report, that increases the risk that the reporter moves on
>  with different sofware/release or abandoning to use the software that
>  causes trouble. 
See [1]

>  Please don't forget that bug reporters have limited time only,
> too. 
Agreed.  Which is why mass-closing is such an appealing thing from
both sides of the fence.  It's been mentioned in this thread (not sure
if on this list or another, I'll go back and look), that the message
used to mass-close should basically admit the fact that we know that
we have a problem, and that we are taking action to fix the problem in
the future so that we don't get into this state again.

>  Bug triagers should focus on filling a queue with tickets, where
> package
>  maintainers commit to taking a serious look at those tickets. 
I think that one of my proposals is going to be a fedora-triage flag
or something similar.  Maintainers can look at that and know that the
bug has been reviewed by a triager, that it's not a duplicate, and
that the priority/version/component settings on the bug are sane.

>  The NEEDINFO
>  state should be used when there is committment to moving forward with a
>  ticket, not just to give the reporter something to do after a long of no
>  interest in the report. 
Are you saying that triagers should not use NEEDINFO for current bugs?
 At that point, there's not developer commitment, there is triager
commitment.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=204883
[2] https://bugzilla.redhat.com/show_bug.cgi?id=427157

[Michael Schwendt]

On Sat, 5 Jan 2008 16:25:53 -0500, Jon Stanley wrote:

>  > t is even more rude to close such old bugs as WONTFIX or
>  > INSUFFICIENT_DATA. When only after the EOL of a distribution version there
>  > is activity within a ticket, that is like saying "we didn't care about
>  > your bug report this time, and we don't promise either that we look into
>  > the issue this time".
>  
>  Is there some other reasonable course of action? 
Rephrase the canned response that is cut'n'pasted into the ticket.

It is not very helpful IMO to point out that a dist version has reached
EOL if the bug was reported while the dist was an active release.

Instead, explain to the reporter *why* the ticket has not been dealt with
for such a long time. This is where triagers must be very careful. The
reporter might believe that the provided details are sufficient and that
the problem is reproducible. It is extremely poor form to not even try
whether the problem is reproducible. And *if* you ask for NEEDINFO, do
tell what is missing. Another reporter may flood a bugzilla ticket with
many pages of [often irrelevant] data, which increases the time it takes
to wade through it. Point to a good web page that explains how to get
backtraces and how to increase the quality of bug reports in general.

>  [...] basically admit the fact that we know that
>  we have a problem, and that we are taking action to fix the problem in
>  the future so that we don't get into this state again. 
If you tell reporters that there are too many bug reports and not enough
people to handle them all, do it early and possibly with an automated
comment, for example after a maintainer has not responded after one month.
Just don't touch old tickets after several months of inactivity only
because there is hope that they can be closed after two weeks of waiting
in NEEDINFO. So, while F9 is being developed, a backlog of F6 tickets
causes a headache? With Fedora's fast-paced development, better focus
on tickets about F8 and rawhide.

>  > The NEEDINFO
>  > state should be used when there is committment to moving forward with a
>  > ticket, not just to give the reporter something to do after a long of no
>  > interest in the report.
>  
>  Are you saying that triagers should not use NEEDINFO for current bugs?
>   At that point, there's not developer commitment, there is triager
>  commitment. 
*What* type of activity can you guarantee after the reporter (or
somebody else) has cleared the NEEDINFO state?

[Bruno Wolff III]

On Sat, Jan 05, 2008 at 16:25:53 -0500,
  Jon Stanley <jonstanley(a)gmail.com&gt; wrote:
>  
>  Agreed.  Which is why mass-closing is such an appealing thing from
>  both sides of the fence.  It's been mentioned in this thread (not sure
>  if on this list or another, I'll go back and look), that the message
>  used to mass-close should basically admit the fact that we know that
>  we have a problem, and that we are taking action to fix the problem in
>  the future so that we don't get into this state again. 
Shouldn't the underlying problem be fixed before doing the mass close?
If not there is likely to be another one down the road while tickets
continue to accumalate before the fix actually happens.

I don't see any rush, as tickets that were being ignored can continue to
be ignored until things are fixed.