Re: [boost] Request for a new submodule, tools/depinst

Subject: Re: [boost] Request for a new submodule, tools/depinst
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-11-11 15:16:31

On 11/11/16 23:00, Rene Rivera wrote:
> On Fri, Nov 11, 2016 at 2:53 PM, Andrey Semashev <andrey.semashev_at_[hidden]>
> wrote:
>
>> On 11/11/16 22:45, Rene Rivera wrote:
>>
>>> On Fri, Nov 11, 2016 at 2:33 PM, Andrey Semashev <
>>> andrey.semashev_at_[hidden]>
>>> wrote:
>>>
>>> On 11/11/16 21:26, Rene Rivera wrote:
>>>>
>>>> On Fri, Nov 11, 2016 at 1:18 PM, Peter Dimov <lists_at_[hidden]> wrote:
>>>>>
>>>>> wgetting a random version rubs me the wrong way. Test results should be
>>>>>
>>>>>> reproducible.
>>>>>>
>>>>>>
>>>>> Hmm.. Are you saying that getting an old version of the regression tools
>>>>> that "matches" a particular checkout of the libraries at some point in
>>>>> time
>>>>> should always work and be a measure of reproduction?
>>>>>
>>>>>
>>>> I think that's correct. In my work, I have a number of scripts to build
>>>> various libraries, some of which are downloaded from git or other SCMs.
>>>> It
>>>> is essential that whenever those scripts are run, they use exactly the
>>>> same
>>>> source to build the package. This is usually achieved by checking out a
>>>> particular tag or revision.
>>>>
>>>
>>> See my answer to this in the other response.. But essentially.. Think
>>> about
>>> what happens when the test infrastructure changes.
>>>
>>
>> Not sure what you mean here.
>
>
> One obvious one.. What would happen when someone checks out and old version
> and the testing infrastructure has change enough that the old version
> doesn't work any longer?

Same thing when he does that with libraries - it would probably not work.

> Do we ignore that possibility and fail in some
> unpredictable way? Do we implement some version checking and fail nicely
> but prevent "users" from running the scripts? Do we want to support
> backward version testing of testing infrastructure to ensure the version
> checking works for all possible past versions against future versions?

That is up to you, the maintainers of the testing infrastructure. As far 
as I'm concerned, it can fail horribly.

My point is that there should be a reliable way to checkout any Boost 
release, at any point in future, and that checkout is synchronized (i.e. 
all components were tested together and testing results were deemed 
satisfactory) and the same every time.

>> I think Boost, as a whole, should support this usage. I realize that
>>>
>>>> checking out a particular revision of each git submodule will always
>>>> work,
>>>> but since we already use superproject as the synchronization means of
>>>> different submodules, checking out a revision of superproject should
>>>> work.
>>>>
>>>
>>> Haha.. That's really funny. The super project gives as much
>>> synchronization
>>> guarantee as a human passing around pieces of physical paper around the
>>> world as he makes changes to them ;-)
>>>
>>
>>   git checkout boost-1.62.0
>>   git submodule update
>>
>> Am I not guaranteed to have Boost 1.62 after these commands? If not,
>> something is terribly wrong with the release process.
>
> You are only guaranteed that because *humans* carefully check-pointed that
> version and verified it with testing. Can't say the same for any other
> random commit outside of the tagged releases though.

Having that guaranteed by humans is a downside, for sure, but the 
important part is that this tag is a synchronization point and it is 
stable (i.e. doesn't change). I did not verify, but I also assume that 
the official release archives are built from the sources that correspond 
to the git tag.

Regarding other commits to the superproject, if I'm not mistaken, they 
are also synchronization points because it is those commits that are 
tested, not the individual commits in submodules. Whenever I look at the 
test matrix I see that synchronized state of Boost. Whether that 
synchronization is predictable or not is not that relevant in this 
discussion (well, at least as it currently works).