Re: [boost] Updated Development and Release Practices for 1.35.0

From: David Abrahams (dave_at_[hidden])
Date: 2007-09-05 16:51:11

on Wed Sep 05 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:

> Beman Dawes wrote:
>
>> Vladimir Prus wrote:
>>> Beman Dawes wrote:
>>> 
>>>> The Development and Release Practices trac wiki page has been updated.
>>>> See http://svn.boost.org/trac/boost/wiki/ImprovingPractices
>>>>
>>>> The most important changes were refinements of the repository
>>>> organization and addition of more specific procedures for merging from
>>>> the trunk to the next release. The merging is described in terms of
>>>> TortoiseSVN. It would be helpful if someone familiar with command line
>>>> svn provided an equivalent set of instructions for command line users.
>>>>
>>>> I'm trying to restrict the process to things we can do right away, so we
>>>> can get started on 1.35.0.
>>> 
>>> I don't think I see the answers to the below question that I've previous
>>> posted:
>>> 
>>> 1. The procedure for merging to release-ready tree needs
>>> more details -- if the procedure is painful, then authors just
>>> won't merge anything.
>> 
>> Yes, the easier the procedure is, the better.
>> 
>> We are strongly urging developers to become familiar with synmerge.py,
>> and use it to simplify branch management See
>> http://www.orcaware.com/svn/wiki/Svnmerge.py.
>> 
>> Incidentally, Subversion 1.5 will build in the functionality of
>> svnmerge.py.
>
> 1. For the branch layout that is proposed, you don't need svnmerge,
> a scrap of paper, of a wiki page, or a manually maintained property
> will work just fine. 

Why do that when svnmerge takes care of it for you?

> 2. What made you think that SVN 1.5 will be compatible with svnmerge
> in any way? 

What made you think Beman thought that?

> Importantly, I can find any indication that properties set by
> svnmerge can be of direct use to SVN 1.5. I'd be happy to be proved
> wrong, BTW.

I'm sure you're right.  I don't think anyone thought differently,
though.

>>> 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?
>> 
>> Sure, as long as it is marked up as an expected failure. There are no
>> plans to change the markup procedures for failing tests AFAIK.
>
> Ok, this makes sense.
>
>>> 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?
>> 
>> Up to the release manager, perhaps after discussion on the. Between the
>> way we tag releases and the facilities of Subversion, the release
>> manager will be able to start from wherever is best. My guess is the the
>> starting point is always the prior release, so the just merged change
>> gets moved aside until the next 1.36.0 release.
>
> "Moved aside" means "reverted"? They are already on release branch. This seems
> weird, this means the work spend merging to release branch is wasted.

Yeah, that would be silly.  Obviously you create a copy of the 1.35.0
tag and start with that for 1.35.1.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
The Astoria Seminar ==> http://www.astoriaseminar.com