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