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

Subject: Re: [boost] [git] Update submodules in boost.git
From: Daniel Pfeifer (daniel_at_[hidden])
Date: 2013-12-05 04:22:52

2013/12/5 Andrey Semashev <andrey.semashev_at_[hidden]>:
> 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.

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