[git] Update submodules in boost.git

newer
[concept_check] Merge changes to...

older
[git] develop and master are two...

Daniel James

5 Dec 2013 5 Dec '13

12:21 a.m.

Hi, I've just updated all the submodules in the main git repo. I'll try and do this daily for a little while, but we'll need to automate it. Preferably triggered by a hook so it's as close to instantaneous as possible. Any takers? Daniel

Show replies by date

Daniel Pfeifer

5 Dec 5 Dec

5:37 a.m.

2013/12/5 Daniel James :

...

Hi,

I've just updated all the submodules in the main git repo. I'll try and do this daily for a little while, but we'll need to automate it. Preferably triggered by a hook so it's as close to instantaneous as possible. Any takers?

The purpose of modularisation was to allow a modular release process. I suggest the following: Each Boost library has its own release schedule. When there is a new release of Boost library X, you point the submodule in Boost/develop to X/master. Tests are run on Boost/develop. To make a new release of Boost, you merge the changes of Boost/develop to Boost/master. At any point in time, Boost/develop contains the latest released versions of all Boost libraries. Boost/master contains the releases of the Boost distribution: I.e. versions of Boost libraries that are tested to play nice together. Cheers, Daniel

Andrey Semashev

6:24 a.m.

On Thu, Dec 5, 2013 at 9:37 AM, Daniel Pfeifer wrote:

...

2013/12/5 Daniel James :

...
Hi,

I've just updated all the submodules in the main git repo. I'll try and do this daily for a little while, but we'll need to automate it. Preferably triggered by a hook so it's as close to instantaneous as possible. Any takers?

The purpose of modularisation was to allow a modular release process. I suggest the following:

Each Boost library has its own release schedule. When there is a new release of Boost library X, you point the submodule in Boost/develop to X/master.

What if a library does not have any releases? I.e. when there is a rolling release which is always HEAD of master? I think many libraries are developed this way, or at least this was the case with svn. I really don't like the idea that I have to do something to bring my changes into the Boost superproject. It's yet another action that I have to remember doing some day, and practice shows that merging from trunk to release is already prone to forgetting.

...

Tests are run on Boost/develop. To make a new release of Boost, you merge the changes of Boost/develop to Boost/master.

Does that mean that X/develop is not tested? Why is it needed then?

Daniel Pfeifer

7:07 a.m.

2013/12/5 Andrey Semashev :

...

On Thu, Dec 5, 2013 at 9:37 AM, Daniel Pfeifer wrote:

...
2013/12/5 Daniel James :

...
Hi,

I've just updated all the submodules in the main git repo. I'll try and do this daily for a little while, but we'll need to automate it. Preferably triggered by a hook so it's as close to instantaneous as possible. Any takers?

The purpose of modularisation was to allow a modular release process. I suggest the following:

Each Boost library has its own release schedule. When there is a new release of Boost library X, you point the submodule in Boost/develop to X/master.

What if a library does not have any releases? I.e. when there is a rolling release which is always HEAD of master? I think many libraries are developed this way, or at least this was the case with svn.

There was an agreement that the gitflow branching model shall be used.

...

I really don't like the idea that I have to do something to bring my changes into the Boost superproject. It's yet another action that I have to remember doing some day, and practice shows that merging from trunk to release is already prone to forgetting.

...
Tests are run on Boost/develop. To make a new release of Boost, you merge the changes of Boost/develop to Boost/master.

Does that mean that X/develop is not tested?

Yes (and no). It is not integrated into Boost and it is not tested as part of Boost. The same way as the development of zlib is not tested by Debian. Just the releases are integrated and tested.

...

Why is it needed then?

According to gitflow, this is where the development of X happens. It is also tested of course. On its own, however. -- Daniel

Vladimir Prus

7:12 a.m.

On 05.12.2013 11:07, Daniel Pfeifer wrote:

...

...
...
Tests are run on Boost/develop. To make a new release of Boost, you merge the changes of Boost/develop to Boost/master.

Does that mean that X/develop is not tested?

Yes (and no). It is not integrated into Boost and it is not tested as part of Boost. The same way as the development of zlib is not tested by Debian. Just the releases are integrated and tested.

...
Why is it needed then?

According to gitflow, this is where the development of X happens. It is also tested of course. On its own, however.

I seems like we use 'gitflow' as a stick, regardless of its merits. For program_options, I am expressly not going to bother with it, I will just commit those couple of patches I get per year directly into master, after verifying that regression tests still work. I suspect that this approach will be most efficient for most libraries that don't see extensive development, and for which separate release schedule makes no sense. - Volodya

Dave Abrahams

7 Dec 7 Dec

10:43 p.m.

Vladimir Prus writes:

...

On 05.12.2013 11:07, Daniel Pfeifer wrote:

...
...
...
Tests are run on Boost/develop. To make a new release of Boost, you merge the changes of Boost/develop to Boost/master.

Does that mean that X/develop is not tested?

Yes (and no). It is not integrated into Boost and it is not tested as part of Boost. The same way as the development of zlib is not tested by Debian. Just the releases are integrated and tested.

...
Why is it needed then?

According to gitflow, this is where the development of X happens. It is also tested of course. On its own, however.

I seems like we use 'gitflow' as a stick, regardless of its merits. For program_options, I am expressly not going to bother with it, I will just commit those couple of patches I get per year directly into master, after verifying that regression tests still work. I suspect that this approach will be most efficient for most libraries that don't see extensive development, and for which separate release schedule makes no sense.

FWIW, committing to master amounts to publishing a new release of your library, FYI. Whether or not you announce it that way or think of it that way, it will be treated as such by the rest of the community and by the Boost release system. As long as you don't mind that, I don't see anything wrong with whatever procedure you choose. Cheers, Dave

Vladimir Prus

8 Dec 8 Dec

8:20 a.m.

On 08.12.2013 02:43, Dave Abrahams wrote:

...

Vladimir Prus writes:

...
On 05.12.2013 11:07, Daniel Pfeifer wrote:

...
...
...
Tests are run on Boost/develop. To make a new release of Boost, you merge the changes of Boost/develop to Boost/master.

Does that mean that X/develop is not tested?

Yes (and no). It is not integrated into Boost and it is not tested as part of Boost. The same way as the development of zlib is not tested by Debian. Just the releases are integrated and tested.

...
Why is it needed then?

According to gitflow, this is where the development of X happens. It is also tested of course. On its own, however.

I seems like we use 'gitflow' as a stick, regardless of its merits. For program_options, I am expressly not going to bother with it, I will just commit those couple of patches I get per year directly into master, after verifying that regression tests still work. I suspect that this approach will be most efficient for most libraries that don't see extensive development, and for which separate release schedule makes no sense.

FWIW, committing to master amounts to publishing a new release of your library, FYI. Whether or not you announce it that way or think of it that way, it will be treated as such by the rest of the community and by the Boost release system.

As long as you don't mind that, I don't see anything wrong with whatever procedure you choose.

I don't mind. (I still think that a 'new release' is a bit too pompous name for minor update to minor library, but anyway). - Volodya

Andrey Semashev

5 Dec 5 Dec

7:43 a.m.

On Thu, Dec 5, 2013 at 11:07 AM, Daniel Pfeifer wrote:

...

2013/12/5 Andrey Semashev :

...
On Thu, Dec 5, 2013 at 9:37 AM, Daniel Pfeifer wrote:

...
2013/12/5 Daniel James :

...
Hi,

I've just updated all the submodules in the main git repo. I'll try and do this daily for a little while, but we'll need to automate it. Preferably triggered by a hook so it's as close to instantaneous as possible. Any takers?

The purpose of modularisation was to allow a modular release process. I suggest the following:

Each Boost library has its own release schedule. When there is a new release of Boost library X, you point the submodule in Boost/develop to X/master.

What if a library does not have any releases? I.e. when there is a rolling release which is always HEAD of master? I think many libraries are developed this way, or at least this was the case with svn.

There was an agreement that the gitflow branching model shall be used.

I thought of it as of one of the possible models. So far boostorg only required develop and master branches as the replacement for trunk and release of svn. Personally, I plan to keep my work flow close to the one I had with svn, i.e. I commit to develop, and when it passes tests I merge it to master. I don't plan to form releases of these merges.

...

...
I really don't like the idea that I have to do something to bring my changes into the Boost superproject. It's yet another action that I have to remember doing some day, and practice shows that merging from trunk to release is already prone to forgetting.

...
Tests are run on Boost/develop. To make a new release of Boost, you merge the changes of Boost/develop to Boost/master.

Does that mean that X/develop is not tested?

Yes (and no). It is not integrated into Boost and it is not tested as part of Boost. The same way as the development of zlib is not tested by Debian. Just the releases are integrated and tested.

...
Why is it needed then?

According to gitflow, this is where the development of X happens. It is also tested of course. On its own, however.

So this basically means that each library has to have its own testing farm, and Boost serves mostly the bundling purpose. A possible solution, I guess, but not sure such approach would be beneficial for the quality of Boost. I doubt that individual developers will be able to do the same amount of testing for their library releases as they had with svn.

Tim Blechmann

7:57 a.m.

...

...
...
...
Tests are run on Boost/develop. To make a new release of Boost, you merge the changes of Boost/develop to Boost/master.

Does that mean that X/develop is not tested?

Yes (and no). It is not integrated into Boost and it is not tested as part of Boost. The same way as the development of zlib is not tested by Debian. Just the releases are integrated and tested.

...
Why is it needed then?

According to gitflow, this is where the development of X happens. It is also tested of course. On its own, however.

So this basically means that each library has to have its own testing farm, and Boost serves mostly the bundling purpose. A possible solution, I guess, but not sure such approach would be beneficial for the quality of Boost. I doubt that individual developers will be able to do the same amount of testing for their library releases as they had with svn.

how and when are things to be tested: * when a commit is done to someLibrary/develop * when superproject/develop updates the submodule reference to someLibrary/develop? tim

Andrey Semashev

8:12 a.m.

On Thu, Dec 5, 2013 at 11:57 AM, Tim Blechmann wrote:

...

...
...
...
...
Tests are run on Boost/develop. To make a new release of Boost, you merge the changes of Boost/develop to Boost/master.

Does that mean that X/develop is not tested?

Yes (and no). It is not integrated into Boost and it is not tested as part of Boost. The same way as the development of zlib is not tested by Debian. Just the releases are integrated and tested.

...
Why is it needed then?

According to gitflow, this is where the development of X happens. It is also tested of course. On its own, however.

So this basically means that each library has to have its own testing farm, and Boost serves mostly the bundling purpose. A possible solution, I guess, but not sure such approach would be beneficial for the quality of Boost. I doubt that individual developers will be able to do the same amount of testing for their library releases as they had with svn.

how and when are things to be tested:

* when a commit is done to someLibrary/develop * when superproject/develop updates the submodule reference to someLibrary/develop?

If you're asking about my preferred approach then the first - when a commit is done to someLibrary/develop. And then again, when it is merged to someLibrary/master. No manual updates to the superproject are required. If I understood Daniel's suggestion, someLibrary/develop is never tested, except by the library developers or maybe free volunteers. someLibrary/master is tested when the superproject/develop is explicitly updated to reference the new commit in someLibrary/master.

Tim Blechmann

8:39 a.m.

...

...
...
So this basically means that each library has to have its own testing farm, and Boost serves mostly the bundling purpose. A possible solution, I guess, but not sure such approach would be beneficial for the quality of Boost. I doubt that individual developers will be able to do the same amount of testing for their library releases as they had with svn.

how and when are things to be tested:

* when a commit is done to someLibrary/develop * when superproject/develop updates the submodule reference to someLibrary/develop?

If you're asking about my preferred approach then the first - when a commit is done to someLibrary/develop. And then again, when it is merged to someLibrary/master. No manual updates to the superproject are required.

i suppose that any other approach would ask for troubles. also, when testing someLibrary/develop it may depend on someOtherLibrary/develop. so if the tests would only run someLibrary/develop with all other dependent libraries checked out on master, one will run into troubles.

...

If I understood Daniel's suggestion, someLibrary/develop is never tested, except by the library developers or maybe free volunteers.

we are then loosing the biggest advantage of the testfarm: being able to see troubles early in the development process on platforms/toolchains the individual developer may not have access to. tim

Andrey Semashev

9:09 a.m.

On Thu, Dec 5, 2013 at 11:43 AM, Andrey Semashev wrote:

...

On Thu, Dec 5, 2013 at 11:07 AM, Daniel Pfeifer wrote:

...
2013/12/5 Andrey Semashev :

...
On Thu, Dec 5, 2013 at 9:37 AM, Daniel Pfeifer wrote:

...
Tests are run on Boost/develop. To make a new release of Boost, you merge the changes of Boost/develop to Boost/master.

Does that mean that X/develop is not tested?

Yes (and no). It is not integrated into Boost and it is not tested as part of Boost. The same way as the development of zlib is not tested by Debian. Just the releases are integrated and tested.

...
Why is it needed then?

According to gitflow, this is where the development of X happens. It is also tested of course. On its own, however.

So this basically means that each library has to have its own testing farm, and Boost serves mostly the bundling purpose. A possible solution, I guess, but not sure such approach would be beneficial for the quality of Boost. I doubt that individual developers will be able to do the same amount of testing for their library releases as they had with svn.

Actually, thinking about it some more, this doesn't look as a good approach at all. First, the develop branch for the submodules becomes unneeded by the superproject. Individual developers may use it at their discretion but it doesn't matter in the big picture. Second, since only the master branch is tested by the test farm, it is likely that the problems will be detected only after the release of the library. In order to fix the problems, the library is bound to perform all the release cycle again. The cycle can be as small as a commit directly to the master branch (which is yet another indication that the develop branch is unneeded), but the important part is that the superproject/develop is broken until the problem is fixed. In order to release Boost we would have to stabilize superproject/develop so that it can be merged to superproject/master, and we all know from experience that such stabilization is an endless process. This was the reason why the original separation between trunk and release, where both are tested, was introduced. To me, this outcome of the suggested approach is a showstopper.

Dave Abrahams

7 Dec 7 Dec

10:45 p.m.

Andrey Semashev writes:

...

On Thu, Dec 5, 2013 at 11:43 AM, Andrey Semashev wrote:

...
On Thu, Dec 5, 2013 at 11:07 AM, Daniel Pfeifer wrote:

...
2013/12/5 Andrey Semashev :

...
On Thu, Dec 5, 2013 at 9:37 AM, Daniel Pfeifer wrote:

...
Tests are run on Boost/develop. To make a new release of Boost, you merge the changes of Boost/develop to Boost/master.

Does that mean that X/develop is not tested?

Yes (and no). It is not integrated into Boost and it is not tested as part of Boost. The same way as the development of zlib is not tested by Debian. Just the releases are integrated and tested.

...
Why is it needed then?

According to gitflow, this is where the development of X happens. It is also tested of course. On its own, however.

So this basically means that each library has to have its own testing farm, and Boost serves mostly the bundling purpose. A possible solution, I guess, but not sure such approach would be beneficial for the quality of Boost. I doubt that individual developers will be able to do the same amount of testing for their library releases as they had with svn.

Actually, thinking about it some more, this doesn't look as a good approach at all. First, the develop branch for the submodules becomes unneeded by the superproject. Individual developers may use it at their discretion but it doesn't matter in the big picture.

And why is that a bad thing? The only purpose of the superproject is as a way of tracking releasable states of the whole library collection.

Cox, Michael

8 Dec 8 Dec

4:02 a.m.

On Sat, Dec 7, 2013 at 3:45 PM, Dave Abrahams wrote:

...

Andrey Semashev writes:

...
On Thu, Dec 5, 2013 at 11:43 AM, Andrey Semashev wrote:

...
On Thu, Dec 5, 2013 at 11:07 AM, Daniel Pfeifer wrote:

...
2013/12/5 Andrey Semashev :

...
On Thu, Dec 5, 2013 at 9:37 AM, Daniel Pfeifer < daniel@pfeifer-mail.de> wrote:

...
Tests are run on Boost/develop. To make a new release of Boost, you merge the changes of Boost/develop to Boost/master.

Does that mean that X/develop is not tested?

Yes (and no). It is not integrated into Boost and it is not tested as part of Boost. The same way as the development of zlib is not tested by Debian. Just the releases are integrated and tested.

...
Why is it needed then?

According to gitflow, this is where the development of X happens. It is also tested of course. On its own, however.

So this basically means that each library has to have its own testing farm, and Boost serves mostly the bundling purpose. A possible solution, I guess, but not sure such approach would be beneficial for the quality of Boost. I doubt that individual developers will be able to do the same amount of testing for their library releases as they had with svn.

Actually, thinking about it some more, this doesn't look as a good approach at all. First, the develop branch for the submodules becomes unneeded by the superproject. Individual developers may use it at their discretion but it doesn't matter in the big picture.

And why is that a bad thing? The only purpose of the superproject is as a way of tracking releasable states of the whole library collection.

And releasable states includes "releases" to the automated (jenkins?) builds, unit-test executions, and any other formal testing activities. That should occur mostly off the develop branches of the superproject and the submodule repositories. Once everything is building, passing unit-tests, and otherwise ready for release, then the develop branches are merged into the master branches and tagged. This does not mean that this all happens at the same time. A particular library/tool's submodule repository's development work for a particular release could be merged into their repository's master branch early before the actual release of boost. Hmmm... I just thought of a flaw in the above scheme. Unfortunately, if some people don't like having two branches, they're really not going to like the following which requires even more branches (one for each release!). According to the gitflow diagramhttp://github.com/downloads/nvie/gitflow/Git-branching-model.pdf , there's a bubble pointing to a branch off of develop with the text "Start of release branch for 1.0" and a bubble pointing to develop with the text "From this point on, next release means the release *after* 1.0". Now assume you have the scenario I mentioned above (an early release of a library for the next boost release). You need an individual release branches so that work for the 1.0+ releases can continue on the develop branch. If you don't separate things into separate release branches you have to freeze development on the develop branch. Also, you would need automated builds/tests on develop and all the active release branches. That seems like a lot of complexity. Is there a better, simpler way? Am I worrying about something that doesn't happen much, if at all? Michael

...

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

Andrey Semashev

8:34 a.m.

On Saturday 07 December 2013 14:45:21 Dave Abrahams wrote:

...

Andrey Semashev writes:

...
On Thu, Dec 5, 2013 at 11:43 AM, Andrey Semashev

...
So this basically means that each library has to have its own testing farm, and Boost serves mostly the bundling purpose. A possible solution, I guess, but not sure such approach would be beneficial for the quality of Boost. I doubt that individual developers will be able to do the same amount of testing for their library releases as they had with svn.

Actually, thinking about it some more, this doesn't look as a good approach at all. First, the develop branch for the submodules becomes unneeded by the superproject. Individual developers may use it at their discretion but it doesn't matter in the big picture.

And why is that a bad thing? The only purpose of the superproject is as a way of tracking releasable states of the whole library collection.

What about testing? To me, the collection is in a releasable state when the testing results show no blocker problems, and this is not a precondition for a given superproject state. It's the other way around - the superproject state accommodates changes from the libraries and every such snapshot is tested whether it is suitable for being released. In the rest of my last quoted message I described why the particular approach for testing could result in negative outcome - problems in the dependent code are not detected by testing until the problematic code is merged to master. It takes longer time for the fix to travel from develop to master again. Later in the discussion Peter assured me that the release managers' job would be to manually select which commits to master are problematic ones and exclude them from the Boost release. This sounds like a tedious task to me, but it would remove the delay in the Boost release at least. But still it doesn't help individual developers since their tests would be broken for longer times and integration problems not detected early.

Peter Dimov

8:09 p.m.

...

Later in the discussion Peter assured me that the release managers' job would be to manually select which commits to master are problematic ones and exclude

Andrey Semashev wrote: them from the Boost release. This sounds like a tedious task to me, but it would remove the delay in the Boost release at least. It's not necessarily tedious because manual intervention would only be required in the cases in which there is a conflict. In this approach, the develop branch of the superproject will be scripted to always point to the tip of the master branches of the library repositories, whereas, per gitflow, the master branch of the superproject will point to the latest release. A new release would be done on a release branch (again, per gitflow) which initially starts from boostorg:develop and, if there are no issues, gets merged into boostorg:master. Reverting boostorg:develop commits on the release branch will only be needed in the rare cases in which a library needs to be rolled back. (It's also possible for boostorg to have a scripted branch, say "latest", which points to "develop" in all libraries, but it would play no role for the releases.) This is, of course, not the only option. It's just one way of doing things.

...

But still it doesn't help individual developers since their tests would be broken for longer times and integration problems not detected early.

As I said, it's a tradeoff. If your library depends on many other libraries, some of which tend to often be broken on their develop branch, you would prefer to test your library against their master branches, since these would hopefully be less broken. This allows you to proceed with your own tests without waiting for the dependencies to clean up their acts.

Tim Blechmann

12:09 p.m.

...

...
Actually, thinking about it some more, this doesn't look as a good approach at all. First, the develop branch for the submodules becomes unneeded by the superproject. Individual developers may use it at their discretion but it doesn't matter in the big picture.

And why is that a bad thing? The only purpose of the superproject is as a way of tracking releasable states of the whole library collection.

what about library dependencies? if lib X depends on a certain version of lib Y? iiuc this information is stored in the superproject as well? in a way i fear the modularized boost is not exactly bisect-friendly, or does git-bisect traverse submodules?

Daniel Pfeifer

5 Dec 5 Dec

9:22 a.m.

2013/12/5 Andrey Semashev :

...

On Thu, Dec 5, 2013 at 11:07 AM, Daniel Pfeifer wrote:

...
2013/12/5 Andrey Semashev :

...
On Thu, Dec 5, 2013 at 9:37 AM, Daniel Pfeifer wrote:

...
2013/12/5 Daniel James :

...
Hi,

I've just updated all the submodules in the main git repo. I'll try and do this daily for a little while, but we'll need to automate it. Preferably triggered by a hook so it's as close to instantaneous as possible. Any takers?

The purpose of modularisation was to allow a modular release process. I suggest the following:

Each Boost library has its own release schedule. When there is a new release of Boost library X, you point the submodule in Boost/develop to X/master.

What if a library does not have any releases? I.e. when there is a rolling release which is always HEAD of master? I think many libraries are developed this way, or at least this was the case with svn.

There was an agreement that the gitflow branching model shall be used.

I thought of it as of one of the possible models. So far boostorg only required develop and master branches as the replacement for trunk and release of svn.

Personally, I plan to keep my work flow close to the one I had with svn, i.e. I commit to develop, and when it passes tests I merge it to master. I don't plan to form releases of these merges.

...
...
I really don't like the idea that I have to do something to bring my changes into the Boost superproject. It's yet another action that I have to remember doing some day, and practice shows that merging from trunk to release is already prone to forgetting.

...
Tests are run on Boost/develop. To make a new release of Boost, you merge the changes of Boost/develop to Boost/master.

Does that mean that X/develop is not tested?

Yes (and no). It is not integrated into Boost and it is not tested as part of Boost. The same way as the development of zlib is not tested by Debian. Just the releases are integrated and tested.

...
Why is it needed then?

According to gitflow, this is where the development of X happens. It is also tested of course. On its own, however.

So this basically means that each library has to have its own testing farm, and Boost serves mostly the bundling purpose.

That is not what I meant. IMO each library shall be tested on its own (against stable releases of other libraries). Of course, boostorg can provide the testing farm for this purpose!

...

A possible solution, I guess, but not sure such approach would be beneficial for the quality of Boost. I doubt that individual developers will be able to do the same amount of testing for their library releases as they had with svn.

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

Andrey Semashev

9:32 a.m.

On Thu, Dec 5, 2013 at 1:22 PM, Daniel Pfeifer wrote:

...

2013/12/5 Andrey Semashev :

...
On Thu, Dec 5, 2013 at 11:07 AM, Daniel Pfeifer wrote:

...
2013/12/5 Andrey Semashev :

...
Does that mean that X/develop is not tested?

Yes (and no). It is not integrated into Boost and it is not tested as part of Boost. The same way as the development of zlib is not tested by Debian. Just the releases are integrated and tested.

...
Why is it needed then?

According to gitflow, this is where the development of X happens. It is also tested of course. On its own, however.

So this basically means that each library has to have its own testing farm, and Boost serves mostly the bundling purpose.

That is not what I meant. IMO each library shall be tested on its own (against stable releases of other libraries). Of course, boostorg can provide the testing farm for this purpose!

I'm confused. What exact parts of library submodules will be tested by the boostorg test farm? develop? master?

Tim Blechmann

9:33 a.m.

...

...
So this basically means that each library has to have its own testing

...
farm, and Boost serves mostly the bundling purpose. That is not what I meant. IMO each library shall be tested on its own (against stable releases of other libraries).

this means that no library can depend of features of another library, which is not part of the stable release or am i missing something?

Peter Dimov

1:13 p.m.

Tim Blechmann wrote:

...

this means that no library can depend of features of another library, which is not part of the stable release or am i missing something?

Yes. X/develop can't depend on Y/develop, only on Y/master. This is not the same as depending on a stable release of Boost though. In practice, both approaches have their pros and cons. Testing everything/develop aids the case in which a breaking change in the interface of Y causes fixes in many other libraries, and the ensuing transition is best kept on develop. On the other hand, testing X/develop against everything/master is better when Y/develop contains mistakes that break the world. Development of X can proceed on X/develop without waiting for Y/develop to be cleaned up.

Mateusz Loskot

1:35 p.m.

On 5 December 2013 13:13, Peter Dimov wrote:

...

Tim Blechmann wrote:

...
this means that no library can depend of features of another library, which is not part of the stable release or am i missing something?

Yes. X/develop can't depend on Y/develop, only on Y/master. ----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

IMHO, that should be displayed in the guidelines in bold. Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net

Edward Diener

2:17 p.m.

On 12/5/2013 8:35 AM, Mateusz Loskot wrote:

...

On 5 December 2013 13:13, Peter Dimov wrote:

...
Tim Blechmann wrote:

...
this means that no library can depend of features of another library, which is not part of the stable release or am i missing something?

Yes. X/develop can't depend on Y/develop, only on Y/master. ----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

IMHO, that should be displayed in the guidelines in bold.

If library X depends on library Y and needs some feature/fix of library Y in order to correctly implement some feature/fix of library X it seems to me that library X/develop can rely on library Y/develop, at least for individual testing of library X. Holding off the feature/fix of library X until Y/develop becomes Y/master seems a PITA to me. I know for my individual testing if my library X/develop needs something from library Y/develop I pull from library Y/develop in order to test. In this scenario library X needs to wait for library Y/develop to go to library Y/master before it goes to library X/master.

Andrey Semashev

2:30 p.m.

On Thu, Dec 5, 2013 at 6:17 PM, Edward Diener wrote:

...

On 12/5/2013 8:35 AM, Mateusz Loskot wrote:

...
On 5 December 2013 13:13, Peter Dimov wrote:

...
Tim Blechmann wrote:

...
this means that no library can depend of features of another library, which is not part of the stable release or am i missing something?

Yes. X/develop can't depend on Y/develop, only on Y/master.

----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

IMHO, that should be displayed in the guidelines in bold.

If library X depends on library Y and needs some feature/fix of library Y in order to correctly implement some feature/fix of library X it seems to me that library X/develop can rely on library Y/develop, at least for individual testing of library X. Holding off the feature/fix of library X until Y/develop becomes Y/master seems a PITA to me.

I know for my individual testing if my library X/develop needs something from library Y/develop I pull from library Y/develop in order to test.

In this scenario library X needs to wait for library Y/develop to go to library Y/master before it goes to library X/master.

I might add that testing X/develop with Y/master has another drawback. When a change is made to Y/develop, it is tested against everything/master. It passes the tests but the change actually breaks X. When the change is merged to Y/master, X is broken and it stays that way until Y cycles again. If this happens during Boost release preparation, these late failures can delay the release significantly. I can see the upsides of this scheme too, but I don't think it should be the only testing scheme. I'd prefer to have everything/develop test results as well.

Peter Dimov

2:46 p.m.

Andrey Semashev wrote:

...

I might add that testing X/develop with Y/master has another drawback. When a change is made to Y/develop, it is tested against everything/master. It passes the tests but the change actually breaks X. When the change is merged to Y/master, X is broken and it stays that way until Y cycles again.

This tends to happen in practice regardless of the testing scheme. The author of X doesn't watch the tests of Y.

Andrey Semashev

2:50 p.m.

On Thu, Dec 5, 2013 at 6:46 PM, Peter Dimov wrote:

...

Andrey Semashev wrote:

...
I might add that testing X/develop with Y/master has another drawback. When a change is made to Y/develop, it is tested against everything/master. It passes the tests but the change actually breaks X. When the change is merged to Y/master, X is broken and it stays that way until Y cycles again.

This tends to happen in practice regardless of the testing scheme. The author of X doesn't watch the tests of Y.

In my example Y tests would succeed, but X would fail if it was tested against Y/develop.

Peter Dimov

2:56 p.m.

Andrey Semashev wrote:

...

On Thu, Dec 5, 2013 at 6:46 PM, Peter Dimov wrote:

...
Andrey Semashev wrote:

...
I might add that testing X/develop with Y/master has another drawback. When a change is made to Y/develop, it is tested against everything/master. It passes the tests but the change actually breaks X. When the change is merged to Y/master, X is broken and it stays that way until Y cycles again.

This tends to happen in practice regardless of the testing scheme. The author of X doesn't watch the tests of Y.

In my example Y tests would succeed, but X would fail if it was tested against Y/develop.

Yes, sorry. "The author of Y doesn't watch the tests of X."

Andrey Semashev

3:03 p.m.

On Thu, Dec 5, 2013 at 6:56 PM, Peter Dimov wrote:

...

Andrey Semashev wrote:

...
On Thu, Dec 5, 2013 at 6:46 PM, Peter Dimov wrote:

...
Andrey Semashev wrote:

...
I might add that testing X/develop with Y/master has another drawback. When a change is made to Y/develop, it is tested against >> everything/master. It passes the tests but the change actually breaks X. When the change

...
...
is merged to Y/master, X is broken and it stays that way until Y cycles >> again.

This tends to happen in practice regardless of the testing scheme. The author of X doesn't watch the tests of Y.

In my example Y tests would succeed, but X would fail if it was tested against Y/develop.

Yes, sorry. "The author of Y doesn't watch the tests of X."

The point is that the maintainer of X notices the problem in Y (which resulted in X breakage) and notifies the maintainer of Y. This is mostly how it happens now. The significant benefit is that in everything/develop scheme the breakage can be fixed before it makes it into the master branch and does not hold off Boost release if it's on the way.

Peter Dimov

4:03 p.m.

Andrey Semashev wrote:

...

The significant benefit is that in everything/develop scheme the breakage can be fixed before it makes it into the master branch and does not hold off Boost release if it's on the way.

The release procedure adapts to that and doesn't blindly package Y/master, but the latest stable commit. In other words, the release manager's job changes from watching everything/master like a hawk for breakages to picking and choosing from everything/master in order to produce a stable release. If X version A.B+1 doesn't work with Y, X version A.B goes into the release.

Mateusz Loskot

2:32 p.m.

On 5 December 2013 14:17, Edward Diener wrote:

...

On 12/5/2013 8:35 AM, Mateusz Loskot wrote:

...
On 5 December 2013 13:13, Peter Dimov wrote:

...
Tim Blechmann wrote:

...
this means that no library can depend of features of another library, which is not part of the stable release or am i missing something?

Yes. X/develop can't depend on Y/develop, only on Y/master. ----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

IMHO, that should be displayed in the guidelines in bold.

If library X depends on library Y and needs some feature/fix of library Y in order to correctly implement some feature/fix of library X it seems to me that library X/develop can rely on library Y/develop, at least for individual testing of library X.

...library Y receives a bug fix and issues a hotfix release merged back to master upon release. ...library Y receives a feature and merges it into develop, then...good question, since Y and X are no longer 'stitched' together they were in SVN trunk. I remember, there was a discussion about testing library (was it serialisation or filesystem?) which had been performed against SVN release branch, not SVN trunk what makes little sense. Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net

Peter Dimov

2:47 p.m.

Mateusz Loskot wrote:

...

I remember, there was a discussion about testing library (was it serialisation or filesystem?) which had been performed against SVN release branch, not SVN trunk

Serialization. Robert has been a big advocate of this testing scheme.

Peter Dimov

2:43 p.m.

Edward Diener wrote:

...

I know for my individual testing if my library X/develop needs something from library Y/develop I pull from library Y/develop in order to test.

What you do for your individual testing is separate from what the test infrastructure does. You have a local repository, in which you can have a local X/develop branch that you test against the remote Y/develop. This is independent of what others see. Of course, if the testing infrastructure tests your remote X/develop against Y/master, you can't push your changes to Github until Y/develop is merged to Y/master on Github. Then again, one might well argue that your development in this case ought to happen on a feature branch that is not develop. (And the same can also be said about Y's development.) Anyway, as I said, both testing systems have their pros and cons. We'll need to pick one and settle on it before real development can resume, though.

Beman Dawes

9:07 p.m.

On Thu, Dec 5, 2013 at 2:07 AM, Daniel Pfeifer wrote:

...

There was an agreement that the gitflow branching model shall be used.

That is too strong. There was agreement to recommend git flow, but the only requirement is that there be a "master" and a "develop" branch, and that "master" be the library's latest release. Beyond that, libraries can do whatever they want in terms of workflow and branches. Git Flow is not the solution, it is a solution. --Beman

Cox, Michael

6 Dec 6 Dec

1:07 a.m.

On Thu, Dec 5, 2013 at 2:07 PM, Beman Dawes wrote:

...

On Thu, Dec 5, 2013 at 2:07 AM, Daniel Pfeifer
...
wrote:

...
There was an agreement that the gitflow branching model shall be used.

That is too strong. There was agreement to recommend git flow, but the only requirement is that there be a "master" and a "develop" branch, and that "master" be the library's latest release.

I've been seeing a lot of e-mail flying around where people seem to be suggesting that development is done on the master instead of the develop branch. If we're requiring that library repositories have a develop and a master branch, is there a requirement that they be treated like the gitflow model does, i.e. development occurs on a local feature branch that is merged to the local develop branch and pushed to boostorg and releases are created on the master branch by merging develop to master and pushing to boostorg? If libraries are free to have there own policies, that's going to get very confusing. Michael

...

Beyond that, libraries can do whatever they want in terms of workflow and branches. Git Flow is not the solution, it is a solution.

--Beman

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

Beman Dawes

2:41 a.m.

On Thu, Dec 5, 2013 at 8:07 PM, Cox, Michael wrote:

...

On Thu, Dec 5, 2013 at 2:07 PM, Beman Dawes wrote:

...
On Thu, Dec 5, 2013 at 2:07 AM, Daniel Pfeifer
...
wrote:

...
There was an agreement that the gitflow branching model shall be used.

That is too strong. There was agreement to recommend git flow, but the only requirement is that there be a "master" and a "develop" branch, and that "master" be the library's latest release.

I've been seeing a lot of e-mail flying around where people seem to be suggesting that development is done on the master instead of the develop branch. If we're requiring that library repositories have a develop and a master branch, is there a requirement that they be treated like the gitflow model does, i.e. development occurs on a local feature branch that is merged to the local develop branch and pushed to boostorg and releases are created on the master branch by merging develop to master and pushing to boostorg? If libraries are free to have there own policies, that's going to get very confusing.

If that happens, we will deal with it. But since it is notoriously "hard to make predictions, especially about the future", let's not get all in an uproar worrying about it. The work of the moment is to come up to speed with git and modular boost, and start to reap the benefits. --Beman

Dave Abrahams

7 Dec 7 Dec

10:49 p.m.

"Cox, Michael" writes:

...

On Thu, Dec 5, 2013 at 2:07 PM, Beman Dawes wrote:

...
On Thu, Dec 5, 2013 at 2:07 AM, Daniel Pfeifer
...
wrote:

...
There was an agreement that the gitflow branching model shall be used.

That is too strong. There was agreement to recommend git flow, but the only requirement is that there be a "master" and a "develop" branch, and that "master" be the library's latest release.

I've been seeing a lot of e-mail flying around where people seem to be suggesting that development is done on the master instead of the develop branch. If we're requiring that library repositories have a develop and a master branch, is there a requirement that they be treated like the gitflow model does, i.e. development occurs on a local feature branch that is merged to the local develop branch and pushed to boostorg and releases are created on the master branch by merging develop to master and pushing to boostorg?

Yes, library maintainers should be prepared for their master branch state to be treated as an assertion of releasability, and should not expect any state not on their master branch to become part of the monolithic boost release.

Daniel James

5 Dec 5 Dec

9:23 a.m.

On 5 December 2013 05:37, Daniel Pfeifer wrote:

...

The purpose of modularisation was to allow a modular release process. I suggest the following:

Each Boost library has its own release schedule. When there is a new release of Boost library X, you point the submodule in Boost/develop to X/master. Tests are run on Boost/develop. To make a new release of Boost, you merge the changes of Boost/develop to Boost/master.

Such a system should also have to deal with hotfixes. But the most important question is, would anyone be willing to implement this?

3990

Age (days ago)

3993

Last active (days ago)

List overview

Download

36 comments

11 participants

participants (11)

Andrey Semashev
Beman Dawes
Cox, Michael
Daniel James
Daniel Pfeifer
Dave Abrahams
Edward Diener
Mateusz Loskot
Peter Dimov
Tim Blechmann
Vladimir Prus