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