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 04:09:47

On Thu, Dec 5, 2013 at 11:43 AM, Andrey Semashev
<andrey.semashev_at_[hidden]> wrote:
> 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:
>>>> 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.