On Fri, 05 Nov 2010 15:15:36 -0700, Adam wrote: > On Fri, 2010-11-05 at 23:09 +0100, Michael Schwendt wrote: > > On Fri, 05 Nov 2010 13:45:37 -0700, Adam wrote: > > > > > > Something is terribly wrong here, if reporter adjusts F12 -> F13 -> F14 > > > > over a period of N months in reply to the automated NEEDINFO requests and > > > > still doesn't get any response other than another automated one after > > > > six more months. > > > > > > So, what's your alternative? > > > > To keep them open, so as they get older and they continue to affect users, > > they could be moved up from the bottom of somebody's TODO list. > > How are we to know they continue to affect users? As a first step, make sure the EOL script never closes a ticket more than once. If it closed it for F12 EOL, a user reassigns it to F13, and then the script closes it once more for F13 EOL, that should be seen as an early-warning system. Worse if a user reassigns it from F12 EOL to F14 or even Rawhide, and still it isn't dealt with for unknown reasons. Further, it's common for users to create duplicates, or to add comments to existing bugzilla tickets, or to add themselves to the Cc field, or to bookmark bz links and visit them every once in a while. Somebody needs to take notice of such activity. The Fedora Wiki suggests that the package maintainers do. Tools like ABRT search for duplicates or (if failing to find a dupe), open a NEW ticket for the same issue. A maintainer or triager, who skims over the stacktrace and categorizes a bz ticket (possibly changing the Subject line to something meaningful), could easily find the old ticket. The old ticket with users in Cc, perhaps useful comments or test-cases. Sometimes it takes weeks or months for someone to consider opening a new ticket, though. Why expect the maintainer to treat new tickets differently than old tickets for the same issue that lives on for months? > > If they get closed, much is lost including test-case attachments, > > comments, links. Eventually somebody will open a new ticket for F15 and > > point out that the package is broken since F8. > > It's not lost, it's all there; the bug is just marked CLOSED. It can be > re-opened if it turns out to be necessary. Who will be the expert to know how to find it? And who will have the necessary time to review closed tickets? > People file new bugs without > looking for duplicates all the time anyway. We usually only catch dupes > through triage efforts or through the developer noticing that a bug > looks like an older one. Exactly. And if incoming bug reports aren't triaged by anyone, closing tickets too early only falsifies the program's condition. A bug opened in 2010 will make it look like it may be a new bug, when in fact EOL scripts have killed old tickets for the same bug multiple times before. > lack of manpower is the ultimate explanation for lack of attention to > bugs whenever I've gone to the trouble of tracking down an explanation. > What other explanation would you posit? - lack of interest - packager too lazy to forward issue upstream - packager not capable of fixing the bug or analyzing the problem - a crap code base (spaghetti-code, poor design, basic coding mistakes e.g.) - package only needed as a dependency - common mindshare among some people that bugzilla is a plague - a high personal package count as the ultimate goal, even if there's the risk that they aren't really maintained It isn't obvious to users and other packagers. > > For example, there's a crash in librsvg2, which affects multiple apps > > that use this library, including Nautilus. There have been multiple > > reports about it. Including an upstream ticket created by me. Including > > a comment on what is wrong in the source and what would be a work-around. > > No response so far. http://bugzilla.redhat.com/553069 > > Other tickets for the same issue are in EOL NEEDINFO state meanwhile. > > For me, even with provenpackager access, it's not clear how to proceed > > even if the issue affects one of my packages, too. > > And whereas I would fix such an issue in my own packages, there are > > lengthy documents like > > https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages > > that make me insecure. > > None of this feels like it has much to do with the EOL process. How > exactly would changing the EOL process help this? How does closing the ticket help at all? There are test-case attachments as the problem is 100% reproducible. There is one work-around. And yet there is a lack of response and nothing about this in the Wiki. The Wiki page linked above just talks about "controversial fixes" or "matter of style" to raise doubts. This EOL process is too independent and ought to be linked with other procedures (orphans, retiring pkgs, non-responsive maintainers, call for volunteers, todo lists, cry for help). -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
