Re: [boost] Release Manager's Checklist added

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-08-07 15:47:58

At 02:10 PM 8/7/2003, Joerg Walter wrote:
 >
 >----- Original Message -----
 >From: "Beman Dawes" <bdawes_at_[hidden]>
 >>
 >> * Monitor inspection report to verify problems are being dealt with.
 >
 >Unsure about that. I remember some mails from a wizard ;-)

Yes, but the release manager has to help too. Or at least monitor progress.

 >
 >> * Monitor regression tests to verify that errors are dealt with.
 >
 >Unsure about that. ublas has some test failures (for ICC on windows for
 >example) which nobody is going to fix probably. OTOH this is the only
 >verification if cvs is consistent.

The actual process for future releases is going to be more sophisticated 
than in the past. For key compilers (those on major platforms with few 
enough bugs that it is possible to look at errors in detail), we can try to 
account for failures (as boost problems, compiler bugs, whatever). For 
example, see the random library tests at 
http://boost.sourceforge.net/regression-logs/cs-win32.html

There are seven failures. Jens has looked each failure, and each has been 
classified. (Except Borland classification which will show up tomorrow.) 
You could say each failure has been "accounted for".

Thus the release manager can see at a glance that this library is ready for 
release.

 >> * Monitor mailing lists to verify that patches are being dealt with.
 >
 >Doesn't sf have a tracker for patches?
 >
 >> * Monitor mailing lists and bug tracker to verify that bug reports are
 >> being dealt with.
 >
 >Doesn't sf have a tracker for bugs?

Yes, to both but we aren't using them fully and/or properly. Also, people 
post patches and bug reports direct to the mailing lists. Sometimes they 
get handled promptly, sometimes not. I've got at least a dozen email 
messages to the main list flagged as "awaiting response", plus lots of S/F 
reports too.

I keep meaning to research the best way to track bugs/patches, but haven't 
found the time. Note that the "best way" may just mean learning to use 
existing SourceForge features better.

 >> * Monitor CVS commits to verify content gets committed as planned.
 >
 >Yep, seems like this one is a problem. Prereleases?

Some kind of task list is more what I had in mind. SourceForge has such a 
feature already; we aren't using it.

Thanks for the questions. Even though programming is much more fun, we need 
to do a certain amount of management to ensure release quality.

--Beman