Geometry Boost List: Re: [geometry] Setting up Travis CI for Boost.Geometry

Subject: Re: [geometry] Setting up Travis CI for Boost.Geometry
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2014-11-10 14:51:34

On 10 November 2014 19:36, Adam Wulkiewicz <adam.wulkiewicz_at_[hidden]> wrote:
> Adam Wulkiewicz wrote:
>> Mateusz Loskot wrote:
>>> On 10 November 2014 16:31, Adam Wulkiewicz <adam.wulkiewicz_at_[hidden]> wrote:
>>>>
>>>> AFIO has many icons in their README but indeed there is only one from
>>>> Travis.
>>>> https://github.com/BoostGSoC13/boost.afio
>>>
>>> Yes, Travis status image is generated per branch build:
>>> https://api.travis-ci.org/mloskot/geometry.svg?branch=master
>>> https://api.travis-ci.org/mloskot/geometry.svg?branch=develop
>>> ,,,
>>> No customisations.
>>>
>>>> What if we made some dummy branches, each one testing one part of the
>>>> library?
>>>
>>> How would that differ from telling b2 what to build?
>>>
>>> b2 target1 target2 target3
>>>
>>> ...but not target4.
>>
>>
>> Since AFAIU Travis generates a result image per branch, the only way to
>> generate multiple images (for various parts of the lib) is to run the tests
>> for various (dummy) branches each testing a part. Those resulting images may
>> be then inserted into one README. Or am I missing something?
>>
>
> Or maybe better, to not create dummy branches in the original repo we could
> have a fork designated for testing with all of the additional branches and
> configuration files, etc.

IMHO, adding any extra planes of build status sounds like an overkill.
We have build status per branch (after last commit).
We decide that we build only those parts that are actively maintained.
We get green, we're good.
We get red, we must fix to get green.

In the Boost.Geometry upstream, this is all we should care about, really:

branch   | status
-----------------------
develop |  GREEN
master  |  GREEN

IMHO, users should be able to get stable (master) or cutting edge (develop)
package of what is actively maintained, without any unsupported legacies.

Regarding extensions that are broken, they either should be fixed
if actively maintained and supported
or moved to separate repository
if not maintained, orphaned and unsupported.

That said, I'd rather consider, either dedicated
repository github.com/boostorg/geometry-extensions
or
Boost.Geometry team organization github.com/boostorg-geometry
where such repositories can be maintained:
github.com/boostorg-geometry/extensions-orphaned
github.com/boostorg-geometry/extensions-proposed
...

my 5 cents

Best regards,
-- 
Mateusz  Loskot, http://mateusz.loskot.net