|
Boost : |
From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-08-07 13:02:00
Beman Dawes wrote:
> A draft "Development and Release Practices" document is up on the Wiki:
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Development_And_Release_Practices
>
> Comments welcomed!
>
> The proposed process refinements are meant to complement the parallel
> ongoing efforts to improve our tools, but don't depend on any tool
> improvements. Thus we can get started as soon as we reach sufficient
> consensus. That said, I think tools are very important, and hope we can
> rapidly make improvements in both process and tools.
I have those questions:
1. The procedure for merging to release-ready tree needs
more details -- if the procedure is painful, then authors just
won't merge anything. Say a great new feature is developed on trunk, but
causes regression on a obscure platform. Author failed
to fix that regression after reasonable effect, and platform
experts failed as well. Can this change go to release tree still?
2. Say Boost 1.35 is released. Week later, a big source-incompatible
change to some library is merged to release-ready tree. Week later, a serious
bug is found in another library. Is there a place where that bug can be
fixed? Release-ready tree already has source-incompatible change to other
library? In other words -- from which tree is 1.35.1 going to be released?
3. Even assuming release-ready tree haven't got any big changes --
what is the planned procedure for fixing issues discovered on release-ready
tree? Trunk might be in the middle on the next big change, so a fix can either
(1) be made on brunch and then merged, or (2) be made on release-ready tree
directly. (1) requires on-demand testing of branches. Is (2) the way to go?
- Volodya
>
> --Beman
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk