Re: [boost] ATTENTION: Library requirements..

Subject: Re: [boost] ATTENTION: Library requirements..
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2016-01-09 09:23:21

Le 08/01/16 17:39, Rene Rivera a écrit :
> On Fri, Jan 8, 2016 at 4:35 AM, Raffi Enficiaud <
> raffi.enficiaud_at_[hidden]> wrote:
>
>> My 2cents...
>>
>> I believe anything that can be generated automatically (and that is
>> currently part of the release toolchain) should be deleted from the
>> repositories.
>
>
> See my previous reply as to why both are there for Predef.

Sorry, I cannot find the piece of information. While you (certainly) can 
provide a good answer for predef, the question remains: would this 
practice of committing generated files be the recommended way?

>
> [snip]
>
>> One thing I would like to point concerning documentation is:
>> - we have all the machinery on the develop and master branches to see the
>> generated documentation: it is 0 effort from the developers to see the
>> documentation as it would be shipped (no need to generate or
>> commit/maintain generated file)
>> - however the frequency of the updates is very low, sometimes once a
>> month: I believe this should be done much more frequently, something like
>> daily by one dedicated runner.
>>
>
> Part of the requirement changes is to do just that. As right now that
> machinery is complicated because of the toolchain setup and, in one case,
> hand written instructions to follow for building library docs. But do not
> despair, I'm working on it. And the current Travis-CI is set up to build
> docs for all libraries on every root update. This is part of supporting
> continuous building of release level archives. Unfortunately that currently
> has two problems:

Well, you (I have the feeling that you support this burden alone... ) 
are facing a problem for maintaining the infrastructure. Wouldn't it be 
the right time for restricting the toolset available to developers? or 
if developers want to do something fancy, they need to contribute to the 
generation toochain as well? As such, contributing to your travis.yml 
(or a Dockerfile for setting up the environment) would be beneficial. 
After all, code development, IT related stuff, etc, are all in the same 
boat.

OTOH, you are proposing a common interface for generating the different 
artifacts of the build (binaries, test results, doc...). If only one 
library needs some special care and departs from that interface, I 
believe those commands can be integrated in the Jamfile directly with 
some black magic. The only thing that is impacted is the surrounding 
environment in which it is generated.

>
> 1. It's failing to build ptr_container docs. See log <
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/100985614/log.txt>.

The coupling here between libraries seems to be problematic as well (and 
also the coupling between doc, test, etc). To me, your are hitting the 
same problem as the discussions we already had concerning the regression 
tests (but this is obviously another topic).

> 2. We don't have a place to reliably upload non-master archives. Currently
> it's set up to upload to bintray.com on the master branch only. As doing
> the uploads on develop got us throttled for uploading too much. So if
> someone has a suggestion that is equivalent to bintray I would love to know
> about it.

I do not know bintray, it certainly does provide a lot of services. But 
I have the feeling that we "only" need a place to store files and make 
them available through a web server (along maybe with their revision, 
branch etc). I should be missing something in thinking that bintray is 
overkill.

We can continue this topic offline or in the test or build ML if you want.

Best regards,
Raffi