On Fri, 04 Jan 2008 13:49:14 -0800 lordmorgul@xxxxxxxxx (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
Attachment:
signature.asc
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
