[boost] is boost a product? was shutdown ticket-system on svn.boost.org

Subject: [boost] is boost a product? was shutdown ticket-system on svn.boost.org
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-01-12 17:39:34

On 1/12/17 2:09 PM, Stefan Seefeld wrote:
> On 12.01.2017 17:01, Mathias Gaunard wrote:
>> On 12 January 2017 at 20:39, Oliver Kowalke <oliver.kowalke_at_[hidden]>
>> wrote:
>>
>>> why not close boost trac for new bug entries while keeping the history and
>>> give the users the hint to enter the bug report in github instead
>>
>> Some Boost libraries have Github issues disabled. That suggests the author
>> prefers to get issues through Trac.
>
> The question of migrating issue tracking never came up formally. So
> perhaps some maintainers simply took for granted that migrating wasn't
> an option ? I think it's at least worth raising the question.
> (Specifically to the library authors / maintainers. There is no sense in
> starting another of those endless tools discussions. Something as simple
> as a quick poll: "would you consider switching to the github tracker, or
> do you prefer to stay with trac ? Only answer with 'yes' or 'no'... ". :-) )
>
>> In practice however, as a bug reporter, I've found that Github works better
>> to iterate quickly on problems and get them fixed.
>
> ...in articular as it's integrated with PR reviews.
>
>
>         Stefan

My objection to all this has nothing to do with any preference I might 
have regarding one system or another.  What I dispute is the concept is 
that boost is a "unified" software package like some software product 
and that we have to agree on the tools being used.  This might have made 
sense at the beginning but it's just grown too much and is too diverse. 
I think the idea that we should agree on things like build system, bug 
tracking system, release dates, documentation format, etc.  is not 
sustainable - if it ever was.  It's a collection of diverse libraries. 
Some are 15 years old, some are C++17, some are huge ambitious efforts 
like ASIO, some are one small simple components like 
BOOST_STATIC_ASSERT.  Some are header only, others need to be compiled. 
The list could go on but you get the idea.

What we should try to agree on are the REQUIREMENTS for boost libraries 
- not how they are implemented.  For example, we might require that 
documentation for a C++ library include explicit concepts - or we might 
not.  We might require that C++ types be documented in terms of 
operations are supported - not on what a class interface should look 
like.  Same goes for testing, and other stuff.

Attempts to agree on something like trac vs github consume a lot of 
time.  The turning the aircraft carrier that is boost takes a lot more 
time and effort.  Then more often than not, by the time this is 
accomplished, there is an even newer cooler gadget available.  It's a 
treadmill without an end.

The incubator shows more or less what I have in mind.  The library 
facade page points to the authors selected repo system, documentation, 
test matrix, issues system, etc.  So varied libraries can have a common 
"interface" but still leave necessary flexibility for individual 
implementers.

Robert Ramey