Re: [boost] [git] Update submodules in boost.git

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