Re: [boost] Release Manager's Checklist added

From: Joerg Walter (jhr.walter_at_[hidden])
Date: 2003-08-08 02:05:08

Hi Beman,

you wrote:

>  >> * 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".

Impressive.

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

OK.

>  >> * 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.

Exactly.

> Also, people
> post patches and bug reports direct to the mailing lists.

That's probably wrong. They should use a tracker first and then discuss them
on the mailing lists.

> Sometimes they
> get handled promptly, sometimes not.

There's no assignment process currently.

> I've got at least a dozen email
> messages to the main list flagged as "awaiting response", plus lots of S/F
> reports too.

So you are responsible for all that stuff? ;-)

> 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.

I believe it's a matter of discipline of the community to use the trackers.

>  >> * 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.

OK.

> Thanks for the questions. Even though programming is much more fun,

I'm currently working in maintenance mode ;-)

> we need
> to do a certain amount of management to ensure release quality.

Agreed.

Best,
Joerg