At 02:10 PM 8/7/2003, Joerg Walter wrote: > >----- Original Message ----- >From: "Beman Dawes" <[EMAIL PROTECTED]> >> >> * 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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
