[boost] Release/bug tracking procedures (Was: [1.34.0] failed to build on cygwin)

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-05-15 04:46:00

Thomas Witt wrote:

> Vladimir Prus wrote:
>> Atry wrote:
>> 
>> 
>>>> As discussed on IRC, this appears to be cygwin-specific bug, making
>>>> build on cygwin impossible. Looks like one between RC3 and final
>>>> release was a bit too hasty ;-)
>>>>
>>>> I believe the attached patch should fix the immediate problem.
>> 
>>> Thanks. But I wonder why is this issue been reported one month ago still
>>> appeared now?  http://lists.boost.org/Archives/boost/2007/04/119537.php
> 
> Looks like it wasn't an issue of haste.
> 
>> Because we don't seem to have any procedure whatsoever in place that
>> makes sure that incoming bug reports are classified with respect to
>> impact on next release, and no procedures that make sure all critical
>> issues are fixed before release?
> 
> Traditionally we did rely on every library maintainer doing exactly that
> tracking and making sure everything is in order for release for their own
> library. 

I'm not sure what you mean "traditionally". I think during earlier
release cycles a somewhat proactive approach to dealing with 
issues was employed.

> Providing regression tests as a help. This obviously does not 
> work anymore.

It actually cannot work. Not all library maintainers are even
available, and if they are available, it's not reasonable to
expect that they read every single email, and therefore bug
report that does not include "[some library name]" in subject
will never reach the right person. 

> It's not procedures that's lacking the most.

Speaking about this particular cygwin bug, it's apparent that procedures
are lacking. 

The current state is that 1.34 release fails to build on cygwin. There's
a patch that seem to fix that, which took some 10 mins to do. So,
why is 1.34 released without that fix?

1. While the bug was reported a month ago, it was
not assigned to me, but to Rene. Why? Who did that assignment?

2. It was not noticed this bug is actually release critical. 

3. The time to test release candidate was way to small, so
this bug was reported for the second time immediately after 1.34 was released.

May I also bring the example of optional? How comes that some critical bug
was discovered day before hard code freeze? While you can also say it's the
problem with individual developer, I'd say it's more result of lack of
any procedures.

While bugs are introduced and fixed by particular persons, most projects
have mechanism to identify what bugs are critical for the next release,
and nudge the right persons into fixing the *right* bugs. It's not exactly
trivial to come with working procedures for Boost, due to great
variety of components and target environments, but it still necessary to try.

- Volodya