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

Subject: Re: [boost] [git] Update submodules in boost.git
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-12-05 02:43:40

On Thu, Dec 5, 2013 at 11:07 AM, Daniel Pfeifer <daniel_at_[hidden]> wrote:
> 2013/12/5 Andrey Semashev <andrey.semashev_at_[hidden]>:
>> On Thu, Dec 5, 2013 at 9:37 AM, Daniel Pfeifer <daniel_at_[hidden]> wrote:
>>> 2013/12/5 Daniel James <daniel_at_[hidden]>:
>>>> 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.