017-01-12 16:53 GMT+01:00 Robert Ramey :

On 1/12/17 2:24 AM, Oliver Kowalke wrote:

...

Hi,

I encountered that the ticket system at svn.boost.org is not up-to-date: components coroutine2 and fiber are missing. At least the reports created for coroutine2 and fiber do not know the components (not in drop-down list).

I would vote for shutdown of the ticket-system in favour of github - for me it makes no sense to manage two bug reporting systems.

The bug reporting system has worked well for me for more than a decade and I wouldn't want to give it up. But I don't believe that everyone has to agree with me. I don't see any value in requiring that all libraries use the same system. Boost can/should require an issue posting sysyem, but doesn't have to mandate which one. So just shut down the system for coroutine and fiber. Problem solved.

note that users still enter bugs for both libraries - but I can't generate reports that select bugs with specific criteria (closed, reopened ...) - seams to me tat the system misses some configuration/maintenance etc. some users enter bugs without specifying the component or assign it to the wrong component ... so simply removing coroutine or fiber will not work properly (at least someone has to move them to the buck tracker at github) at the moment I've to check two bug trackers - that's not nice

On 12.01.2017 12:40, Paul A. Bristow wrote:

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: 12 January 2017 15:54 To: boost@lists.boost.org Subject: Re: [boost] shutdown ticket-system on svn.boost.org

...

Hi,

I encountered that the ticket system at svn.boost.org is not up-to-date: components coroutine2 and fiber are missing. At least the reports created for coroutine2 and fiber do not know the components (not in drop-down list).

I would vote for shutdown of the ticket-system in favour of github - for me it makes no sense to manage two bug reporting systems. The bug reporting system has worked well for me for more than a decade and I wouldn't want to give it up. But I don't believe that everyone has to agree with me. I don't see any value in requiring that all

On 1/12/17 2:24 AM, Oliver Kowalke wrote: libraries use the same system. Boost can/should require an issue posting sysyem, but doesn't have to mandate which one. So just shut down the system for coroutine and fiber. Problem solved. Sort of +1

But you are right that a unified system is needed to move forward.

I'm not sure about that. While certain boost components are so interdependent that users won't be able to tell them apart (and report issues to specific trackers), at least some boost components are independent enough that I don't think a common tracker is needed or even useful. (My usual example: Boost.Python)

Ideas - and especially action - welcome.

But we must not lose the over-a-decade of history, and there are lots of links to Trac items in the documentation.

While I agree in theory (about not wanting to lose history), I have to admit that at this point I'm mostly just worried about the signal-to-noise ratio. The (trac) Wiki for example is full of history - so much history that it's almost impossible to make out the current state. So at the risk of being accused of promoting false dichotomies, I'd argue that a clear status is more important than a complete history. Stefan

Paul

--- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- ...ich hab' noch einen Koffer in Berlin...

On 1/12/17 9:45 AM, John Maddock wrote:

...

The bug reporting system has worked well for me for more than a decade and I wouldn't want to give it up. But I don't believe that everyone has to agree with me. I don't see any value in requiring that all libraries use the same system. Boost can/should require an issue posting sysyem, but doesn't have to mandate which one. So just shut down the system for coroutine and fiber. Problem solved.

Not really: if a component is missing from Trac, then folks will still submit issues there (under the wrong component), and someone will either have to manually move it to Github, or close it down with an explanation - in which case the reporter may well just go off in a huff rather than re-file in the correct place.

OK - then just leave a pointer in the place where you don't want it reported to point to the place you do. I don't care what we use, but it has to

be easy to move reports between components, which IMO means some degree of integration.

I really want to avoid infrastructure projects which create more work than they actually save. At the end of the day it's library developer's who have to spend lot's of time using the system and/or getting involved in it's design so we're not stuck with a bunch more useless work. Robert Ramey

John.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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. In practice however, as a bug reporter, I've found that Github works better to iterate quickly on problems and get them fixed.

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

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Stefan Seefeld Sent: 12 January 2017 22:09 To: boost@lists.boost.org Subject: Re: [boost] shutdown ticket-system on svn.boost.org

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

I'd go with that (with notice) - provided the GitHub bug tracker system can provide an equivalent way of linking reports to a changes-in-this-version history that *should* come with every library.

...

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.

I think I recall that it was discussed but put in the 'too-difficult drawer' for the time being ;-) And the issue keeps bubbling up from time to time...

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 particular as it's integrated with PR reviews.

It's the natural flavour-or-the-year *assumption* with GITs ;-) Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

On 13.01.2017 07:12, Paul A. Bristow wrote:

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Stefan Seefeld Sent: 12 January 2017 22:09 To: boost@lists.boost.org Subject: Re: [boost] shutdown ticket-system on svn.boost.org

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 I'd go with that (with notice) - provided the GitHub bug tracker system can provide an equivalent way of linking reports to a changes-in-this-version history that *should* come with every library.

Good integration with github (including PRs) is one of the most important and compelling reasons to use the github issue trackers, IMO.

...

...

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. I think I recall that it was discussed but put in the 'too-difficult drawer' for the time being ;-)

Well, perhaps it was framed wrongly ? For avoidance of doubt: I'm fully with Robert here: the question shouldn't be whether all boost projects should switch to github issue tracking, but rather whether they *may* move away from the trac tracker to whatever they else they prefer.

And the issue keeps bubbling up from time to time...

Because the current situation is quite unsatisfactory. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 13 January 2017 at 08:02, Olaf van der Spek wrote:

Maybe, maybe not. What libs do have Github disabled?

Most of them. On the first page of https://github.com/boostorg, the only ones that have issues are fiber, process, hana, sort, atomic, accumulators, geometry, context and thread.

On 13 January 2017 at 12:09, Stefan Seefeld wrote:

I'm not sure what information you find on that page, that supposedly indicates whether a project uses github issue tracking,

The information is not on that page, you need to click each repository to see whether it has issues or not.

but your list is incomplete.

Of course it's incomplete, looking at each repository individually is quite tedious, so I only looked at the first page. It looks like it was made to be disabled for all repositories when boost migrated to github, but then new projects have it enabled. Also a few authors have re-enabled it.