Re: [boost] [1.36.0] Libraries with unmerged changes?

From: James Sharpe (james.sharpe_at_[hidden])
Date: 2008-07-11 12:57:27

2008/7/11 David Abrahams <dave_at_[hidden]>:

>
> Yes, that is "standard practice."  But standard practice for projects
> that care about stability is also that failures are not allowed to
> persist on the trunk.

This isn't necessarily the case; take the linux kernel for example which
does care about stability, but the workflow they currently use ensures
stability when it comes to release time, but in between during the 'merge
window' instability is allowed.

Speaking only for myself here, it seems like we can't get people to
> operate that way; a really stable trunk, and development on branches
> just don't seem to be in our culture as a group.  That's why I think
> we're maintaining a separate stable release branch.

 I think that the reason development on branches isn't in the groups culture
is because boost is actually a number of projects all under one umbrella
title 'boost'. This means that there is little code contention because there
is a high degree of code ownership; I get the impression that people
generally don't hack on others code that much, apart from the odd bug fix.
The other reason branches tend not to get used is that you don't get testing
on other platforms.

I am frankly not sure why Beman is inspecting the differences; it was my
> presumption that we could do development in trunk without worrying about
> it, because the release branch is explicitly separated.
>

Indeed, I understand that he is making sure that developers have merged
changes they intended to merge; as I know a number of them missed the
official merge cutoff date, but again learning from the kernel release
process, the equivalent 'merge window' caught out some developers initially
but they were strict about it; I think that boost should take a similar
stance since the developers learnt that they had to get their changes in
during the window or wait for the next release, and once the momentum of
releases picked up this was less of an issue. It also has helped with
maintaining stability; since developers will tend to concentrate on working
towards a particular release; if you know your changes are going to take
slightly longer to develop then you target the next release, and by using
DVCS this is easily done and doesn't ever create any confusion as the
developer maintains his/her branch until its ready for integration upon
which point a integration request is made and either further, wider testing
occurs or it gets merged into the next release.

James