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-04-2008, 07:11 PM
"Jon Stanley"
 
Default Fwd: closing out old bugs of unmaintained releases

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/msg00009.html
[2] https://www.redhat.com/archives/fedora-marketing-list/2008-January/msg00000.html

---------- Forwarded message ----------
From: Jon Stanley <jonstanley@gmail.com>
Date: Jan 4, 2008 1:45 PM
Subject: closing out old bugs of unmaintained releases
To: fedora-advisory-board@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@fedoraproject.org

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-04-2008, 07:11 PM
"Jon Stanley"
 
Default Fwd: closing out old bugs of unmaintained releases

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/msg00009.html
[2] https://www.redhat.com/archives/fedora-marketing-list/2008-January/msg00000.html

---------- Forwarded message ----------
From: Jon Stanley <jonstanley@gmail.com>
Date: Jan 4, 2008 1:45 PM
Subject: closing out old bugs of unmaintained releases
To: fedora-advisory-board@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@fedoraproject.org

--
Fedora-marketing-list mailing list
Fedora-marketing-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-marketing-list
 
Old 01-04-2008, 08:07 PM
Kevin Fenzi
 
Default Fwd: closing out old bugs of unmaintained releases

On Fri, 4 Jan 2008 15:11:51 -0500
jonstanley@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/msg00009.html
> [2]
> https://www.redhat.com/archives/fedora-marketing-list/2008-January/msg00000.html
>
> ---------- Forwarded message ----------
> From: Jon Stanley <jonstanley@gmail.com>
> Date: Jan 4, 2008 1:45 PM
> Subject: closing out old bugs of unmaintained releases
> To: fedora-advisory-board@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
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-04-2008, 08:49 PM
Andrew Farris
 
Default Fwd: closing out old bugs of unmaintained releases

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@gmail.com> <ajfarris@gmail.com>
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
---- ----

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-04-2008, 09:31 PM
 
Default Fwd: closing out old bugs of unmaintained releases

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-04-2008, 11:10 PM
Kevin Fenzi
 
Default Fwd: closing out old bugs of unmaintained releases

On Fri, 04 Jan 2008 13:49:14 -0800
lordmorgul@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-181b0c70022aca0d7aa42d42f7ed12a553189882
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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-05-2008, 11:28 AM
Till Maas
 
Default Fwd: closing out old bugs of unmaintained releases

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
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-05-2008, 03:47 PM
Michael Schwendt
 
Default Fwd: closing out old bugs of unmaintained releases

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.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-05-2008, 04:25 PM
"Jon Stanley"
 
Default Fwd: closing out old bugs of unmaintained releases

On Jan 4, 2008 7:10 PM, Kevin Fenzi <kevin@scrye.com> 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-181b0c70022aca0d7aa42d42f7ed12a553189882
> 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=unmaintained-open&namedowner=jonstanley%40gmail.com
[2] https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamed&namedcmd=F7-open&namedowner=jonstanley%40gmail.com
[3] https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamed&namedcmd=F8-open&namedowner=jonstanley%40gmail.com
[4] https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamed&namedcmd=rawhide-open&namedowner=jonstanley%40gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-05-2008, 05:03 PM
Till Maas
 
Default Fwd: closing out old bugs of unmaintained releases

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
--
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 07:34 PM.

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