F11: things to check in a release tree before a release

[Kevin Fenzi]

On Thu, 20 Nov 2008 12:42:52 +0100
mschwendt at gmail.com (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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081123/9efafbc2/attachment.sig>