A proposal for superproject structure and testing

Peter Dimov

9 Dec 2013 9 Dec '13

12:16 p.m.

To expand on what I said in a previous message, I suggest the following structure for the superproject: - branch "latest": automatically tracks "develop" of submodules (scripted). - branch "develop": automatically tracks "master" of submodules (scripted). - branch "master": contains either the last release or the current release candidate. (This naming reflects a gitflow model. An alternative would be to use the more traditional unstable/stable for latest/develop.) Test runners test all three, in sequence. Release preparation starts with a gitflow release branch from boostorg:develop. The release manager then runs local tests and, if necessary, applies fixes on the branch by downgrading submodules to an earlier version or asking the submodule maintainer to resolve a problem and then upgrading the submodule to the later version. Ideally, this release branch should be tested non-locally. However, in the past switching branches for testing has proved a problem. Therefore, the procedure continues instead with: When the release manager is satisfied with the local test results for the release branch, he merges it to master. This becomes a release candidate. If tests prove satisfactory, the release candidate is tagged as an official release and the release branch is deleted. If not, work continues on the release branch.

Show replies by date

Andrey Semashev

9 Dec 9 Dec

12:32 p.m.

On Monday 09 December 2013 14:16:33 Peter Dimov wrote:

...

To expand on what I said in a previous message, I suggest the following structure for the superproject:

- branch "latest": automatically tracks "develop" of submodules (scripted). - branch "develop": automatically tracks "master" of submodules (scripted). - branch "master": contains either the last release or the current release candidate.

(This naming reflects a gitflow model. An alternative would be to use the more traditional unstable/stable for latest/develop.)

I'd name latest as bleeding-edge, but that's not important.

...

Test runners test all three, in sequence.

Am I correct that all develop branches will be tested together, not library X/develop + everything else/master? I'm ok with that, just wanted to make sure.

...

Release preparation starts with a gitflow release branch from boostorg:develop. The release manager then runs local tests and, if necessary, applies fixes on the branch by downgrading submodules to an earlier version or asking the submodule maintainer to resolve a problem and then upgrading the submodule to the later version.

Ideally, this release branch should be tested non-locally. However, in the past switching branches for testing has proved a problem. Therefore, the procedure continues instead with:

When the release manager is satisfied with the local test results for the release branch, he merges it to master. This becomes a release candidate. If tests prove satisfactory, the release candidate is tagged as an official release and the release branch is deleted. If not, work continues on the release branch.

Looks ok to me. In case if there is a hotfix from some library, is it possible to create a pull request for a particular commit to the library master? Or should it be addressed in this list?

Peter Dimov

1:50 p.m.

Andrey Semashev wrote:

...

Am I correct that all develop branches will be tested together, not library X/develop + everything else/master? I'm ok with that, just wanted to make sure.

That's how I see it, yes. This has the advantage of not requiring any changes to the test script, apart from teaching it to use git instead of svn.

...

Looks ok to me. In case if there is a hotfix from some library, is it possible to create a pull request for a particular commit to the library master? Or should it be addressed in this list?

Both seem fine to me, so it would be up to the release managers to state a preference for one or the other. We'll also need a procedure for the case in which a submodule maintainer is unresponsive or missing. The submodule organization differs from the old SVN world in that the superproject can only refer to a sumbodule commit, so the superproject release branch can't, for example, revert a problematic commit from a submodule. In this case, a release manager would have to create a release branch in the submodule as well, fix things there, and then point boostorg:master to that branch.

Andrey Semashev

2 p.m.

On Monday 09 December 2013 15:50:05 Peter Dimov wrote:

...

We'll also need a procedure for the case in which a submodule maintainer is unresponsive or missing. The submodule organization differs from the old SVN world in that the superproject can only refer to a sumbodule commit, so the superproject release branch can't, for example, revert a problematic commit from a submodule.

In this case, a release manager would have to create a release branch in the submodule as well, fix things there, and then point boostorg:master to that branch.

I think it would be more productive to just fix the problem in develop and then in master of the submodule. The Community team initiative suggested by Beman is supposed to address that case. It would not necessarily be the release manager's job to do the right fix, but rather the community (or more precisely, those of the community who possibly know the library better).

Peter Dimov

2:32 p.m.

Andrey Semashev wrote:

...

I think it would be more productive to just fix the problem in develop and then in master of the submodule.

We're using different meanings of "fix" here. Imagine that the submodule has the following sequence of commits: - bug fix - new feature - bug fix - more of new feature - bug fix and the new feature turns out to block the Boost release. Fixing the problem, in your sense, means fixing the new feature so that it becomes Boost-release-worthy. This should indeed be done in develop. Fixing the problem, in my sense, means doing - revert "more of new feature" - revert "new feature" on a branch. Sure, fixing the new feature is more productive. It's also a lot slower process over which the release managers have no control.

Andrey Semashev

2:47 p.m.

On Monday 09 December 2013 16:32:18 Peter Dimov wrote:

...

Andrey Semashev wrote:

...
I think it would be more productive to just fix the problem in develop and then in master of the submodule.

We're using different meanings of "fix" here. Imagine that the submodule has the following sequence of commits:

- bug fix - new feature - bug fix - more of new feature - bug fix

and the new feature turns out to block the Boost release. Fixing the problem, in your sense, means fixing the new feature so that it becomes Boost-release-worthy. This should indeed be done in develop. Fixing the problem, in my sense, means doing

- revert "more of new feature" - revert "new feature"

on a branch.

Sure, fixing the new feature is more productive. It's also a lot slower process over which the release managers have no control.

You can "revert" the feature by just changing the reference to the commit in the superproject release branch to an earlier commit, before the feature was added to the library master. Of course, it won't be that simple if other libraries rely on the added feature, and in this case it may be simpler to fix the feature instead of reverting. In both cases you don't need extra branches in the submodule. My main concern with these branches is that it's not clear what the library maintainers should do with them. If these fixes are considered valuable than why not do them in the normal way in the first place? After all, master is advertised as the releasable state of the library, not some personal branch of the release manager.

Steven Watanabe

2:57 p.m.

AMDG On 12/09/2013 06:47 AM, Andrey Semashev wrote:

...

On Monday 09 December 2013 16:32:18 Peter Dimov wrote:

...
Andrey Semashev wrote: We're using different meanings of "fix" here. Imagine that the submodule has the following sequence of commits:

- bug fix - new feature - bug fix - more of new feature - bug fix

and the new feature turns out to block the Boost release. Fixing the problem, in your sense, means fixing the new feature so that it becomes Boost-release-worthy. This should indeed be done in develop. Fixing the problem, in my sense, means doing

- revert "more of new feature" - revert "new feature"

on a branch.

<snip>

You can "revert" the feature by just changing the reference to the commit in the superproject release branch to an earlier commit, before the feature was added to the library master.

No you can't. Look at Peter's example again. Doing this would also revert the other bug fixes. In Christ, Steven Watanabe

Andrey Semashev

3:12 p.m.

On Monday 09 December 2013 06:57:13 Steven Watanabe wrote:

...

AMDG

On 12/09/2013 06:47 AM, Andrey Semashev wrote:

...
On Monday 09 December 2013 16:32:18 Peter Dimov wrote:

...
Andrey Semashev wrote: We're using different meanings of "fix" here. Imagine that the submodule has the following sequence of commits:

- bug fix - new feature - bug fix - more of new feature - bug fix

and the new feature turns out to block the Boost release. Fixing the problem, in your sense, means fixing the new feature so that it becomes Boost-release-worthy. This should indeed be done in develop. Fixing the problem, in my sense, means doing

- revert "more of new feature" - revert "new feature"

on a branch.

<snip>

You can "revert" the feature by just changing the reference to the commit in the superproject release branch to an earlier commit, before the feature was added to the library master.

No you can't. Look at Peter's example again. Doing this would also revert the other bug fixes.

Maybe the submodule should be forked then. The superproject would then reference the master branch of the fork with the necessary modifications. At least, this would make sure that the superproject release will stay valid as long as the fork is present. With the branch approach, the branch can be deleted, and if I'm not mistaken, the release tag would then reference a non- existent commit of the branch.

Peter Dimov

5:11 p.m.

Andrey Semashev wrote:

...

With the branch approach, the branch can be deleted, and if I'm not mistaken, the release tag would then reference a non-existent commit of the branch.

What happens with the commit if the branch is deleted but the superproject still references it is an interesting git question. :-) Ideally, the feature will be fixed for the next release in a normal manner, so the question will be moot in addition to interesting, but in practice, it would probably still hold some relevance. :-) Either way, forking seems a but heavy-handed.

Andrey Semashev

5:20 p.m.

On Mon, Dec 9, 2013 at 9:11 PM, Peter Dimov wrote:

...

Andrey Semashev wrote:

...
With the branch approach, the branch can be deleted, and if I'm not mistaken, the release tag would then reference a non-existent commit of the branch.

What happens with the commit if the branch is deleted but the superproject still references it is an interesting git question. :-)

Ideally, the feature will be fixed for the next release in a normal manner, so the question will be moot in addition to interesting, but in practice, it would probably still hold some relevance. :-)

Well, you should be able to check out any Boost release from git (starting from the first git-based release), at least that's expected from a VCS, don't you agree?

Andrey Semashev

8:36 p.m.

On Monday 09 December 2013 19:11:44 Peter Dimov wrote:

...

Andrey Semashev wrote:

...
With the branch approach, the branch can be deleted, and if I'm not mistaken, the release tag would then reference a non-existent commit of the branch.

What happens with the commit if the branch is deleted but the superproject still references it is an interesting git question. :-)

Ideally, the feature will be fixed for the next release in a normal manner, so the question will be moot in addition to interesting, but in practice, it would probably still hold some relevance. :-)

Either way, forking seems a but heavy-handed.

Do tags warrant the tagged commit from deletion? The release procedure could be adjusted so that in every submodule, the commit that went into the Boost release is tagged with some appropriate name (e.g boost_1_56_0). The release manager's branches can then be deleted so that they don't clutter the list of branches. This has the additional benefit of that each submodule contains the information about the state corresponding to every superproject release.

Bjørn Roald

8:42 p.m.

On 12/09/2013 09:36 PM, Andrey Semashev wrote:

...

On Monday 09 December 2013 19:11:44 Peter Dimov wrote:

...
Andrey Semashev wrote:

...
With the branch approach, the branch can be deleted, and if I'm not mistaken, the release tag would then reference a non-existent commit of the branch.

What happens with the commit if the branch is deleted but the superproject still references it is an interesting git question. :-)

Ideally, the feature will be fixed for the next release in a normal manner, so the question will be moot in addition to interesting, but in practice, it would probably still hold some relevance. :-)

Either way, forking seems a but heavy-handed.

Do tags warrant the tagged commit from deletion?

Yes any ref will, both branches and tags are refs. -- Bjørn

Alexander Lamaison

5:17 p.m.

Andrey Semashev writes:

...

On Monday 09 December 2013 06:57:13 Steven Watanabe wrote:

...
AMDG

On 12/09/2013 06:47 AM, Andrey Semashev wrote:

...
On Monday 09 December 2013 16:32:18 Peter Dimov wrote:

...
Andrey Semashev wrote: We're using different meanings of "fix" here. Imagine that the submodule has the following sequence of commits:

- bug fix - new feature - bug fix - more of new feature - bug fix

and the new feature turns out to block the Boost release. Fixing the problem, in your sense, means fixing the new feature so that it becomes Boost-release-worthy. This should indeed be done in develop. Fixing the problem, in my sense, means doing

- revert "more of new feature" - revert "new feature"

on a branch.

<snip>

You can "revert" the feature by just changing the reference to the commit in the superproject release branch to an earlier commit, before the feature was added to the library master.

No you can't. Look at Peter's example again. Doing this would also revert the other bug fixes.

Maybe the submodule should be forked then. The superproject would then reference the master branch of the fork with the necessary modifications. At least, this would make sure that the superproject release will stay valid as long as the fork is present. With the branch approach, the branch can be deleted, and if I'm not mistaken, the release tag would then reference a non- existent commit of the branch.

Do you mean that a superproject commit {foo} tagged "mytag" would reference a non-existent submodule commit {bar} because {bar} had been on branch "mybranch" when commit {foo} was made and branch "mybranch" has since been deleted? Because, if so, that's not possible with git. Branches are just nicknames for particular commits. They can come and go pretty much as they please without disrupting other things. Submodules reference a _commit_ and the commits remain in the repository regardless of what happens to the branches. Or put another way, branches are there for the humans. When talking to itself (like referencing a submodule) git only cares about commits. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

Andrey Semashev

5:24 p.m.

On Mon, Dec 9, 2013 at 9:17 PM, Alexander Lamaison wrote:

...

Andrey Semashev writes:

...
With the branch approach, the branch can be deleted, and if I'm not mistaken, the release tag would then reference a non- existent commit of the branch.

Do you mean that a superproject commit {foo} tagged "mytag" would reference a non-existent submodule commit {bar} because {bar} had been on branch "mybranch" when commit {foo} was made and branch "mybranch" has since been deleted?

Yes.

...

Because, if so, that's not possible with git. Branches are just nicknames for particular commits. They can come and go pretty much as they please without disrupting other things. Submodules reference a _commit_ and the commits remain in the repository regardless of what happens to the branches.

Or put another way, branches are there for the humans. When talking to itself (like referencing a submodule) git only cares about commits.

Ok, good to know. Thanks for the clarification.

Vladimir Prus

5:36 p.m.

On 09.12.2013 21:17, Alexander Lamaison wrote:

...

Because, if so, that's not possible with git. Branches are just nicknames for particular commits. They can come and go pretty much as they please without disrupting other things. Submodules reference a _commit_ and the commits remain in the repository regardless of what happens to the branches.

Then what does 'git gc' do? - Volodya

Alexander Lamaison

7:29 p.m.

Vladimir Prus writes:

...

On 09.12.2013 21:17, Alexander Lamaison wrote:

...
Because, if so, that's not possible with git. Branches are just nicknames for particular commits. They can come and go pretty much as they please without disrupting other things. Submodules reference a _commit_ and the commits remain in the repository regardless of what happens to the branches.

Then what does 'git gc' do?

Good point. I forgot about this. So, in general, the referenced submodule needs to include the commit in _some_ branch for the superproject to definitely reference a valid commit. However, I think the discussion was about a commit already merged to the submodule's master branch, so gc won't touch it. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

Andrey Semashev

7:41 p.m.

On Monday 09 December 2013 19:29:59 Alexander Lamaison wrote:

...

Vladimir Prus writes:

...
On 09.12.2013 21:17, Alexander Lamaison wrote:

...
Because, if so, that's not possible with git. Branches are just nicknames for particular commits. They can come and go pretty much as they please without disrupting other things. Submodules reference a _commit_ and the commits remain in the repository regardless of what happens to the branches.

Then what does 'git gc' do?

Good point. I forgot about this. So, in general, the referenced submodule needs to include the commit in _some_ branch for the superproject to definitely reference a valid commit.

However, I think the discussion was about a commit already merged to the submodule's master branch, so gc won't touch it.

Not necessarily. In my example a boost release (i.e. a tagged commit to the superproject's master) references a commit in a submodule branch that is neither develop nor master. That branch may never be merged to develop or master.

Bjørn Roald

7:44 p.m.

On 12/09/2013 08:41 PM, Andrey Semashev wrote:

...

On Monday 09 December 2013 19:29:59 Alexander Lamaison wrote:

...
Vladimir Prus writes:

...
On 09.12.2013 21:17, Alexander Lamaison wrote:

...
Because, if so, that's not possible with git. Branches are just nicknames for particular commits. They can come and go pretty much as they please without disrupting other things. Submodules reference a _commit_ and the commits remain in the repository regardless of what happens to the branches.

Then what does 'git gc' do?

Good point. I forgot about this. So, in general, the referenced submodule needs to include the commit in _some_ branch for the superproject to definitely reference a valid commit.

However, I think the discussion was about a commit already merged to the submodule's master branch, so gc won't touch it.

Not necessarily. In my example a boost release (i.e. a tagged commit to the superproject's master) references a commit in a submodule branch that is neither develop nor master. That branch may never be merged to develop or master.

There is a reason git branch -d release-1.2.3 will fail with an error if the branch you attempt to delete is not fully merged. -- Bjørn

Andrey Semashev

7:53 p.m.

On Monday 09 December 2013 20:44:58 Bjørn Roald wrote:

...

On 12/09/2013 08:41 PM, Andrey Semashev wrote:

...
On Monday 09 December 2013 19:29:59 Alexander Lamaison wrote:

...
Vladimir Prus writes:

...
On 09.12.2013 21:17, Alexander Lamaison wrote:

...
Because, if so, that's not possible with git. Branches are just nicknames for particular commits. They can come and go pretty much as they please without disrupting other things. Submodules reference a _commit_ and the commits remain in the repository regardless of what happens to the branches.

Then what does 'git gc' do?

Good point. I forgot about this. So, in general, the referenced submodule needs to include the commit in _some_ branch for the superproject to definitely reference a valid commit.

However, I think the discussion was about a commit already merged to the submodule's master branch, so gc won't touch it.

Not necessarily. In my example a boost release (i.e. a tagged commit to the superproject's master) references a commit in a submodule branch that is neither develop nor master. That branch may never be merged to develop or master.

There is a reason

git branch -d release-1.2.3

will fail with an error if the branch you attempt to delete is not fully merged.

There is also git branch -D...

Bjørn Roald

8:23 p.m.

On 12/09/2013 08:53 PM, Andrey Semashev wrote:

...

On Monday 09 December 2013 20:44:58 Bjørn Roald wrote:

...
On 12/09/2013 08:41 PM, Andrey Semashev wrote:

...

...
...
Not necessarily. In my example a boost release (i.e. a tagged commit to the superproject's master) references a commit in a submodule branch that is neither develop nor master. That branch may never be merged to develop or master.

There is a reason

git branch -d release-1.2.3

will fail with an error if the branch you attempt to delete is not fully merged.

There is also git branch -D...

right, my point is that there is a difference between these two options, and we should use -d. The -D option is for when you really mean to get rid of what the branch contain, not just the branch ref. -- Bjørn

Alexander Lamaison

7:56 p.m.

Andrey Semashev writes:

...

On Monday 09 December 2013 19:29:59 Alexander Lamaison wrote:

...
Vladimir Prus writes:

...
On 09.12.2013 21:17, Alexander Lamaison wrote:

...
Because, if so, that's not possible with git. Branches are just nicknames for particular commits. They can come and go pretty much as they please without disrupting other things. Submodules reference a _commit_ and the commits remain in the repository regardless of what happens to the branches.

Then what does 'git gc' do?

Good point. I forgot about this. So, in general, the referenced submodule needs to include the commit in _some_ branch for the superproject to definitely reference a valid commit.

However, I think the discussion was about a commit already merged to the submodule's master branch, so gc won't touch it.

Not necessarily. In my example a boost release (i.e. a tagged commit to the superproject's master) references a commit in a submodule branch that is neither develop nor master. That branch may never be merged to develop or master.

You mean a special branch quickly made to revert a specific thing before a superproject release but not part of the submodule's mainline development (i.e. develop)? Surely those commits would be merged into the submodule master? After all, they form part of a release, both for the submodule and the superproject. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

Andrey Semashev

8:05 p.m.

On Monday 09 December 2013 19:56:10 Alexander Lamaison wrote:

...

Andrey Semashev writes:

...
On Monday 09 December 2013 19:29:59 Alexander Lamaison wrote:

...
However, I think the discussion was about a commit already merged to the submodule's master branch, so gc won't touch it.

Not necessarily. In my example a boost release (i.e. a tagged commit to the superproject's master) references a commit in a submodule branch that is neither develop nor master. That branch may never be merged to develop or master.

You mean a special branch quickly made to revert a specific thing before a superproject release but not part of the submodule's mainline development (i.e. develop)?

Yes.

...

Surely those commits would be merged into the submodule master? After all, they form part of a release, both for the submodule and the superproject.

It didn't look like that from what Peter was suggesting. I'll re-post his example: <quote> Imagine that the submodule has the following sequence of commits: - bug fix - new feature - bug fix - more of new feature - bug fix and the new feature turns out to block the Boost release. Fixing the problem, in your sense, means fixing the new feature so that it becomes Boost-release-worthy. This should indeed be done in develop. Fixing the problem, in my sense, means doing - revert "more of new feature" - revert "new feature" on a branch. </quote> I don't see why such a branch would ever be merged to the main library branches (develop or master), unless the maintainer decides to drop the new features permanently.

Alexander Lamaison

8:36 p.m.

Andrey Semashev writes:

...

On Monday 09 December 2013 19:56:10 Alexander Lamaison wrote:

...
Andrey Semashev writes:

...
On Monday 09 December 2013 19:29:59 Alexander Lamaison wrote:

...
However, I think the discussion was about a commit already merged to the submodule's master branch, so gc won't touch it.

Not necessarily. In my example a boost release (i.e. a tagged commit to the superproject's master) references a commit in a submodule branch that is neither develop nor master. That branch may never be merged to develop or master.

You mean a special branch quickly made to revert a specific thing before a superproject release but not part of the submodule's mainline development (i.e. develop)?

Yes.

...
Surely those commits would be merged into the submodule master? After all, they form part of a release, both for the submodule and the superproject.

It didn't look like that from what Peter was suggesting. I'll re-post his example:

<quote> Imagine that the submodule has the following sequence of commits:

- bug fix - new feature - bug fix - more of new feature - bug fix

and the new feature turns out to block the Boost release. Fixing the problem, in your sense, means fixing the new feature so that it becomes Boost-release-worthy. This should indeed be done in develop. Fixing the problem, in my sense, means doing

- revert "more of new feature" - revert "new feature"

on a branch. </quote>

I don't see why such a branch would ever be merged to the main library branches (develop or master), unless the maintainer decides to drop the new features permanently.

The 'master' branch means 'this was a release'. It doesn't mean 'this was an ideal version of the library'. Eventually the maintainer would need to re-try the feature, at which point it would be merged from 'develop' to 'master' and take over from the quickly-fixed version. If the submodule uses the git-flow model, the quick-fix would be done on the 'hotfix' branch. Then that would be merged into 'master' and form part of the superproject's master. Later the 'hotfix' branch should be merged back into 'develop' and the feature would have to be re-done on top of it. If the submodule is using some other branching model, they don't have to merge the hotfix back in but it should still appear on 'master'. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

Peter Dimov

5:05 p.m.

Andrey Semashev wrote:

...

You can "revert" the feature by just changing the reference to the commit in the superproject release branch to an earlier commit, before the feature was added to the library master.

Not if the commits introducing the feature are intermingled with commits fixing bugs in the existing code, as in my example.

...

My main concern with these branches is that it's not clear what the library maintainers should do with them.

Nothing. They are a stopgap measure.

Cox, Michael

11:07 p.m.

On Mon, Dec 9, 2013 at 5:16 AM, Peter Dimov wrote:

...

To expand on what I said in a previous message, I suggest the following structure for the superproject:

- branch "latest": automatically tracks "develop" of submodules (scripted). - branch "develop": automatically tracks "master" of submodules (scripted). - branch "master": contains either the last release or the current release candidate.

(This naming reflects a gitflow model. An alternative would be to use the more traditional unstable/stable for latest/develop.)

Test runners test all three, in sequence.

Release preparation starts with a gitflow release branch from boostorg:develop. The release manager then runs local tests and, if necessary, applies fixes on the branch by downgrading submodules to an earlier version or asking the submodule maintainer to resolve a problem and then upgrading the submodule to the later version.

Ideally, this release branch should be tested non-locally. However, in the past switching branches for testing has proved a problem. Therefore, the procedure continues instead with:

When the release manager is satisfied with the local test results for the release branch, he merges it to master. This becomes a release candidate. If tests prove satisfactory, the release candidate is tagged as an official release and the release branch is deleted. If not, work continues on the release branch.

I'm not sure I understand the need for a "latest" branch for the cross-linking of the superproject's develop branch with the submodules' master branches. I'm assuming the criteria to merge a feature branch to the develop branch is that it builds and the unit-tests all pass with the current HEADs of the develop branches of all the other submodules. If that's the case, shouldn't the superproject's develop branch be tracking the develop branches of the submodules? This way what your building/testing is more like what you plan on releasing. Changes in the develop branch correspond to changes that are intended for the *next *release (see the gitflow modelhttp://github.com/downloads/nvie/gitflow/Git-branching-model.pdf ). At some point in the development cycle of a release (e.g., release candidate time?), you create a release branch from develop in all the repositories and any last minute showstopper RC fixes go in them. Work can continue in the develop branches for the next, *next *release in parallel, i.e. no need to "freeze" the develop branch. Once every thing is building and passing in the release branches, the release branches can be (fast-forward?) merged into the master branches. Before deleting the release branches you'll want to rebase the RC changes onto develop so that any changes that occurred on the develop branch in parallel now look like they came after the RC changes. This will make it consistent with the eventual state of the master branch. Michael

...

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

Peter Dimov

11:42 p.m.

Cox, Michael wrote:

...

Changes in the develop branch correspond to changes that are intended for the *next* release...

The develop submodule branch will eventually become the next *submodule* release. The master submodule branch is the current submodule release and will eventually be part of the next Boost release. The boostorg develop branch will (approximately) become the next Boost release. The boostorg master branch is (approximately) the current Boost release. The "latest" boostorg branch may or may not correspond to a Boost release. There's no way to tell. Submodule develop->master merges happen asynchronously with respect to the release cycle. This particular submodule configuration may never be released.

...

I'm assuming the criteria to merge a feature branch to the develop branch is that it builds and the unit-tests all pass with the current HEADs of the develop branches of all the other submodules.

That's very unlikely. One, nobody does a full Boost test cycle before integrating work into develop, because a single compiler takes (I think) 8 hours or so, and you need at least two, if not more. Two, unit tests don't just have to pass on a single compiler, and the test infrastructure doesn't take "test my feature branch please" requests at the moment. So you have to merge to develop in order to have the change tested on the full range of compilers. In practice, our current workflow has been: you test locally on a few compilers, merge (or push) into develop, wait three days to a week for the tests to cycle, and if everything looks fine and nobody politely informs you that their library suddenly broke, merge into master. Or forget to merge into master, as the case might often be with svn.

Rob Stewart

10 Dec 10 Dec

11:06 a.m.

On Dec 9, 2013, at 6:42 PM, "Peter Dimov" wrote:

...

Cox, Michael wrote:

...
Changes in the develop branch correspond to changes that are intended for the *next* release...

The develop submodule branch will eventually become the next *submodule* release. The master submodule branch is the current submodule release and will eventually be part of the next Boost release.

[snip]

...

...
I'm assuming the criteria to merge a feature branch to the develop branch is that it builds and the unit-tests all pass with the current HEADs of the develop branches of all the other submodules.

That's very unlikely.

I agree, and not just for Peter's reasons which I snipped. I think submodule testing should be against master of all (or most in special, coordinated evolution cases) other submodules. (This aligns with Robert Ramey's development and testing ideas.) It isn't sensible to test against unreleased commits to other submodules since the bleeding edge can have lots of churn. The idealized process of creating a Boost release then means snagging the latest release commit from each submodule. I'm sure I've missed something, but that approach seems right. ___ Rob (Sent from my portable computation engine)

Cox, Michael

12 Dec 12 Dec

6:54 a.m.

On Tue, Dec 10, 2013 at 4:06 AM, Rob Stewart wrote:

...

On Dec 9, 2013, at 6:42 PM, "Peter Dimov" wrote:

...
Cox, Michael wrote:

...
Changes in the develop branch correspond to changes that are intended for the *next* release...

The develop submodule branch will eventually become the next *submodule* release. The master submodule branch is the current submodule release and will eventually be part of the next Boost release.

[snip]

...
...
I'm assuming the criteria to merge a feature branch to the develop branch is that it builds and the unit-tests all pass with the current HEADs of the develop branches of all the other submodules.

That's very unlikely.

I agree, and not just for Peter's reasons which I snipped. I think submodule testing should be against master of all (or most in special, coordinated evolution cases) other submodules. (This aligns with Robert Ramey's development and testing ideas.)

It isn't sensible to test against unreleased commits to other submodules since the bleeding edge can have lots of churn.

It all depends on what the merge criteria from a feature branch to the develop branch is. If the criteria includes running a release build and unit-tests for the developer's compiler/platform then an automated build/test across all platforms/compilers is likely to pass, providing value information on the stability of the software earlier in the development cycle. Also, if several libraries merge onto master near the end of a boost development cycle, that sounds too much like big-bang integration. Michael

...

The idealized process of creating a Boost release then means snagging the latest release commit from each submodule.

I'm sure I've missed something, but that approach seems right.

___ Rob

(Sent from my portable computation engine)

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Beman Dawes

10 Dec 10 Dec

4:16 p.m.

On Mon, Dec 9, 2013 at 6:42 PM, Peter Dimov wrote:

...

Cox, Michael wrote:

...

I'm assuming the criteria to merge a feature branch to the develop branch

...
is that it builds and the unit-tests all pass with the current HEADs of the develop branches of all the other submodules.

That's very unlikely. One, nobody does a full Boost test cycle before integrating work into develop, because a single compiler takes (I think) 8 hours or so, and you need at least two [platforms], if not more. Two, unit tests don't just have to pass on a single compiler, and the test infrastructure doesn't take "test my feature branch please" requests at the moment. So you have to merge to develop in order to have the change tested on the full range of compilers.

In practice, our current workflow has been: you test locally on a few compilers, merge (or push) into develop, wait three days to a week for the tests to cycle, and if everything looks fine and nobody politely informs you that their library suddenly broke, merge into master. Or forget to merge into master, as the case might often be with svn.

In other words, Boost testing has complexity l*m*n where l is the number of libraries, m is the number of platforms, and n is the number of compilers for the platform. That's the reality behind Peter's suggestions. Git and modular boost can reduce some of the fallout, but we still have to cope with that underlying reality. --Beman

Cox, Michael

12 Dec 12 Dec

7:15 a.m.

On Tue, Dec 10, 2013 at 9:16 AM, Beman Dawes wrote:

...

On Mon, Dec 9, 2013 at 6:42 PM, Peter Dimov wrote:

...
Cox, Michael wrote:

...

...
is that it builds and the unit-tests all pass with the current HEADs of

I'm assuming the criteria to merge a feature branch to the develop branch the

...
develop branches of all the other submodules.

That's very unlikely. One, nobody does a full Boost test cycle before integrating work into develop, because a single compiler takes (I think) 8 hours or so, and you need at least two [platforms], if not more. Two, unit tests don't just have to pass on a single compiler, and the test infrastructure doesn't take "test my feature branch please" requests at the moment. So you have to merge to develop in order to have the change tested on the full range of compilers.

In practice, our current workflow has been: you test locally on a few compilers, merge (or push) into develop, wait three days to a week for the tests to cycle, and if everything looks fine and nobody politely informs you that their library suddenly broke, merge into master. Or forget to merge into master, as the case might often be with svn.

In other words, Boost testing has complexity l*m*n where l is the number of libraries, m is the number of platforms, and n is the number of compilers for the platform.

I don't expect the criteria to merge changes from a feature branch to the develop branch to be successful builds/tests for *all *supported compilers/platforms (that sounds like a good criteria for merging the develop branches into the master branches). I would expect something along the lines of an incremental build of a freshly pulled set of repositories and running the tests for your compiler/platform. If this merge criteria isn't suitable, what is the merge criteria? Will it be consistent for all libraries or will it vary depending on the nature of the library, e.g., whether the library is "small", "medium", or "large"? How would "small", "medium", or "large" be defined? Michael

...

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Peter Dimov

1:09 p.m.

Cox, Michael wrote:

...

I don't expect the criteria to merge changes from a feature branch to the develop branch to be successful builds/tests for *all *supported compilers/platforms (that sounds like a good criteria for merging the develop branches into the master branches). I would expect something along the lines of an incremental build of a freshly pulled set of repositories and running the tests for your compiler/platform.

Sure, that's just common sense and basically what we've been already doing. A change to the public develop branch (the svn trunk in the old world) implies that local testing *of the submodule* has been done. Not of all of Boost; this takes too much time even on a single compiler/platform. (This doesn't specify whether the local change to the develop branch has been a feature branch merge or something else; it doesn't matter.) In practice, a single compiler is not enough; on Windows, one needs at least one version of MSVC, at least one version of GCC, at least one non-C++11 compiler, at least one C++11 compiler.

Cox, Michael

7:05 p.m.

On Thu, Dec 12, 2013 at 6:09 AM, Peter Dimov wrote:

...

Cox, Michael wrote:

...
I don't expect the criteria to merge changes from a feature branch to the develop branch to be successful builds/tests for *all *supported compilers/platforms (that sounds like a good criteria for merging the develop branches into the master branches). I would expect something along the lines of an incremental build of a freshly pulled set of repositories and running the tests for your compiler/platform.

Sure, that's just common sense and basically what we've been already doing. A change to the public develop branch (the svn trunk in the old world) implies that local testing *of the submodule* has been done. Not of all of Boost; this takes too much time even on a single compiler/platform. (This doesn't specify whether the local change to the develop branch has been a feature branch merge or something else; it doesn't matter.)

Yes, but common sense is just so uncommon these days :-). Does "local testing * of the submodule*" include running the unit-tests of the the other submodules to see if you've broken anything in someone elses submodule that depends on yours? And BTW, I was Googling and looking through Boost.Build documentation and couldn't figure out how to easily run all the tests for all the libraries. I would assume there is a target you could pass b2 to run all the unit-tests. What is it?

...

In practice, a single compiler is not enough; on Windows, one needs at least one version of MSVC, at least one version of GCC, at least one non-C++11 compiler, at least one C++11 compiler.

Wow, that's a lot of combinations. Is that the "official" Boost policy, i.e. is there a link on the web-site I can read this? Will that be the official policy for all Boost libraries or can individual libraries define their own? Michael

Peter Dimov

7:24 p.m.

Cox, Michael wrote:

...

Does "local testing * of the submodule*" include running the unit-tests of the the other submodules to see if you've broken anything in someone elses submodule that depends on yours?

No, it generally does not. Perhaps it ought to, in principle, but as touching anything in a core (and sometimes not so-core) library triggers a recompile of nearly all of Boost, it's just not done, at least as far as I know. I can't speak for all maintainers, of course. Perhaps someone does test all of Boost on each change. I don't.

...

Wow, that's a lot of combinations. Is that the "official" Boost policy, i.e. is there a link on the web-site I can read this?

I'm not sure if there is official policy on that. We've mostly been relying on common sense. What I described was just my experience about what needs to be done for a reasonably good local test coverage (today). In the past, it helped to include an EDG-based compiler because EDG was the least permissive regarding not-entirely-legal C++. Nowadays, g++ is mostly strict enough, but soon one would need to include clang as well. And of course there are enough differences between C++03 and C++11 (even if the submodule doesn't have C++11-specific parts) to warrant testing on both.

Steven Watanabe

7:41 p.m.

AMDG On 12/12/2013 11:05 AM, Cox, Michael wrote:

...

And BTW, I was Googling and looking through Boost.Build documentation and couldn't figure out how to easily run all the tests for all the libraries. I would assume there is a target you could pass b2 to run all the unit-tests. What is it?

Run b2 in $BOOST_ROOT/status. In Christ, Steven Watanabe

Edward Diener

8:10 p.m.

On 12/12/2013 2:05 PM, Cox, Michael wrote:

...

On Thu, Dec 12, 2013 at 6:09 AM, Peter Dimov wrote:

...
Cox, Michael wrote:

...
I don't expect the criteria to merge changes from a feature branch to the develop branch to be successful builds/tests for *all *supported compilers/platforms (that sounds like a good criteria for merging the develop branches into the master branches). I would expect something along the lines of an incremental build of a freshly pulled set of repositories and running the tests for your compiler/platform.

Sure, that's just common sense and basically what we've been already doing. A change to the public develop branch (the svn trunk in the old world) implies that local testing *of the submodule* has been done. Not of all of Boost; this takes too much time even on a single compiler/platform. (This doesn't specify whether the local change to the develop branch has been a feature branch merge or something else; it doesn't matter.)

Yes, but common sense is just so uncommon these days :-).

Does "local testing * of the submodule*" include running the unit-tests of the the other submodules to see if you've broken anything in someone elses submodule that depends on yours?

The other way around. If you have dependencies on other libraries you can run your 'develop' tests with the 'develop' branch of those other libraries. Then you can notify some dependent library if their changes break your own tests. I would also run the 'develop' tests against 'master' for all libraries also at some time. This is no difference in principal than developing any other software.

...

And BTW, I was Googling and looking through Boost.Build documentation and couldn't figure out how to easily run all the tests for all the libraries. I would assume there is a target you could pass b2 to run all the unit-tests. What is it?

No one except regression testers is tasked with this.

...

...
In practice, a single compiler is not enough; on Windows, one needs at least one version of MSVC, at least one version of GCC, at least one non-C++11 compiler, at least one C++11 compiler.

Wow, that's a lot of combinations. Is that the "official" Boost policy, i.e. is there a link on the web-site I can read this? Will that be the official policy for all Boost libraries or can individual libraries define their own?

It's just a suggestion, I believe. In Windows I use various releases of gcc and VC++. In Linux various releases of gcc, clang, Intel C++, and occasionally Sun C++, although the latter is a bit buggy. If you have C++03 aned C++0x features you try to test both sides.

Daniel James

8:21 p.m.

On 9 December 2013 12:16, Peter Dimov wrote:

...

To expand on what I said in a previous message, I suggest the following structure for the superproject:

- branch "latest": automatically tracks "develop" of submodules (scripted). - branch "develop": automatically tracks "master" of submodules (scripted). - branch "master": contains either the last release or the current release candidate.

(This naming reflects a gitflow model. An alternative would be to use the more traditional unstable/stable for latest/develop.)

I'd rather use the alternative names. It's a bit confusing to have a "develop" branch which doesn't have "develop" submodules.

...

Test runners test all three, in sequence.

I like that this fits our current capabilities. But I worry about the increased demand of running three branches, the tests were already cycling pretty slowly with just two branches. I suppose we wouldn't need to run master until the later stages of a release cycle, which might help.

...

Release preparation starts with a gitflow release branch from boostorg:develop. The release manager then runs local tests and, if necessary, applies fixes on the branch by downgrading submodules to an earlier version or asking the submodule maintainer to resolve a problem and then upgrading the submodule to the later version.

I think that task would need to be shared out amongst more than one person. It shouldn't be too hard to coordinate with an online spreadsheet or something similar.

Peter Dimov

8:32 p.m.

Daniel James wrote:

...

...
Test runners test all three, in sequence.

I like that this fits our current capabilities. But I worry about the increased demand of running three branches, the tests were already cycling pretty slowly with just two branches. I suppose we wouldn't need to run master until the later stages of a release cycle, which might help.

If test runners don't do a run if there haven't been any new commits to the branch, this would hopefully not place much additional strain on the system since in this scheme master is updated very occasionally.

4004

Age (days ago)

4007

Last active (days ago)

List overview

Download

36 comments

11 participants

participants (11)

Alexander Lamaison
Andrey Semashev
Beman Dawes
Bjørn Roald
Cox, Michael
Daniel James
Edward Diener
Peter Dimov
Rob Stewart
Steven Watanabe
Vladimir Prus