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

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 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