On Thu, 20 Nov 2008 12:42:52 +0100 mschwendt@xxxxxxxxx (Michael Schwendt) wrote: > That worked fine till bug-triagers threatened to close bugzilla > tickets because of dist EOL and then mass-closed them later. Too much > extra burden -- having to revisit tickets and verify the issues and > likely doing it again next EOL is reached. > > What was missing is a script to maintain the bugzilla ticket numbers, > to detect fixed packages (which no longer appear on the list), to > help with closing tickets, and to add reminders to the tickets > automatically. > > And, of course, official backup from FESCo would be nice and helpful, > too. Else it's not worthwhile to file such tickets. Because packagers > may decide for themselves whether they consider an issue important > enough (even if it causes real problems, which are reproducible in Yum > installation scenarios). Thinking about this, and with recent events, I wonder if we shouldn't have some kind of standard way to treat mass issues like: - FTBFS - Source url issues - Provides/Requires issues. - Conflicting files. - Broken EVR between releases. - Initscripts enabled by default. - Summary needs re-writing. - Spec otherwise not up to current specs. Currently, these sorts of things take several tacks: - Just post to devel list and hope maintainer fixes them. * Many maintainers don't read or notice their package in the sea of other posts. - Mail maintainer directly and hope they fix them. * Maintainers might ignore, drop, mean to fix later but forget, etc. - File bugzilla bugs. * Have to keep maintaining them so they don't drop off EOL * Lots of overhead in filing and managing. It seems that we go through this kind of thing every once in a while, and some kind of standard way might be worth figuring out. Perhaps there is a scale where we might have something like FESCo decide: A) This is a simple, needed fix, it's clear how to fix it with a script. Just mass fix all packages in CVS. B) This fix is minor, collect all minor issues and mail maintainers/devel list once a month or something with a summary of them. One email with all issues and clearly indicating the package, etc. Perhaps have just a pointer to a web page listing all the issues for each package? C) This fix is complicated, needs maintainer to deal with. File bug and make sure it's tracked. if not fixed by needed time, drop package or escalate. D) Tie checks where they can be automated into the cvs commits or other points, so notifications are emailed out to maintainers right after they do a checkin. This would only work with minor items that are easy to catch in a script. E) Your clever idea here. I know how much people hate more red tape, but having a policy to follow for these should prevent maintainers from being annoyed by mass mailings and other such things. thoughts? 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
