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. best regards, Oliver
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. Robert Ramey
best regards, Oliver
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
017-01-12 16:53 GMT+01:00 Robert Ramey <ramey@rrsd.com>:
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
-----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
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.
Sort of +1 But you are right that a unified system is needed to move forward. 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. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
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...
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. 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. John.
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
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
On 12 January 2017 at 20:39, Oliver Kowalke <oliver.kowalke@gmail.com> 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 12.01.2017 17:01, Mathias Gaunard wrote:
On 12 January 2017 at 20:39, Oliver Kowalke <oliver.kowalke@gmail.com> 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 -- ...ich hab' noch einen Koffer in Berlin...
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@gmail.com> 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
2017-01-12 23:39 GMT+01:00 Robert Ramey <ramey@rrsd.com>:
I think the idea that we should agree on things like build system, bug tracking system, release dates, documentation format, etc. is not sustainable
I still believe that it was and still is a good idea - diversity in build system, bug tracking system, release dates ... would end in a desaster - boost should be consistent in least in the items you mentioned. User do not want to be forced to look what boost library 'xyz' uses for bug tracking while boost library 'abc' uses a complete different tool. Especially developers need to be able to referre/link in one bug report to another bug (potentialy in another boost library).
-----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 <oliver.kowalke@gmail.com> 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
Le 13/01/2017 à 13:12, Paul A. Bristow a écrit :
-----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 <oliver.kowalke@gmail.com> 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 ;-)
I mentioned that Atlassian Jira has a trac importer in a previous post (I am a Jira advocate and Jira admin, and I can deploy/maintain a jira instance for boost if needed). Concerning "trac 2 github", there are some stuff out there: a quick googling gives this: http://stackoverflow.com/questions/6671584/how-to-export-trac-to-github-issu... I would like to give my 2 cents: * I do not know if any new version would be better. The one of svn.boost.org dates back to 2010. Then the migration from trac "old" to trac "new" to me has the same level of risks than "trac to github" * I do not think that trac is that bad, especially as a maintainer of a boost library. It does the job, it does not prevent ppl from using features of github (PR, code inline comments, etc). * So far, I always redirected users to trac and *nobody* told me it is impossible because their eyes are bleeding when they use trac. If a user wants a bug to get fixed, he knows that he should go through it. * I would rather block totally the wiki part of trac, because trac is really an impediment to having a good boost developer documentation right now, and as a matter of fact, this is what it is right now. Trac is really not helping there. * I would say that there are some tools maintained by some "boost angels". I would be happy to help them maintaining an infrastructure as well. I agree with ppl saying that this is merely "a proposal" of tools, especially for ppl like me that would prefer to focus on the development than on those tools, and that are "ok" with trac. * I also would like to say that this is a recurrent topic. Means that it consumes a lot of time and effort, and creates a lot of noise. OTOH, it means that a good amount of ppl would feel better if those concerns are addressed. So it smells like some changes should be done. If we look at the past, svn2git was in definitive a particularly good move for developers... The ppl pushing for the change cannot expect that everything would happen by itself or all the work be done by "some other boost guy". Those ppl are also quite demanding when it comes to support their own development with tools, and I believe they should provide the same to the boost community. So I suggest those start exploring alternatives to trac, write clear pros/cons, *test* production ready migration tools, write documentation on how to do things, and make them visible on a sandbox. This takes time and effort, but I would say that if everything is at the end done as well as the svn2git was done, then change will be accepted quite seamlessly. Raffi
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 <oliver.kowalke@gmail.com> 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 Thu, Jan 12, 2017 at 11:01 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
On 12 January 2017 at 20:39, Oliver Kowalke <oliver.kowalke@gmail.com> 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.
Maybe, maybe not. What libs do have Github disabled?
In practice however, as a bug reporter, I've found that Github works better to iterate quickly on problems and get them fixed.
Trac is a nightmare, especially for reporters. -- Olaf
On 13 January 2017 at 08:02, Olaf van der Spek <ml@vdspek.org> 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.01.2017 04:47, Mathias Gaunard wrote:
On 13 January 2017 at 08:02, Olaf van der Spek <ml@vdspek.org> 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.
I'm not sure what information you find on that page that supposedly indicates whether a project uses github issue tracking, but your list is incomplete. Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 13 January 2017 at 12:09, Stefan Seefeld <stefan@seefeld.name> 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.
On 01/13/17 15:30, Mathias Gaunard wrote:
On 13 January 2017 at 12:09, Stefan Seefeld <stefan@seefeld.name> 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.
I never re-enabled it for Boost.Log and yet github issues are enabled. So I'm guessing it's the other way around - the issues were disabled by some maintainers manually.
participants (9)
-
Andrey Semashev -
John Maddock -
Mathias Gaunard -
Olaf van der Spek -
Oliver Kowalke -
Paul A. Bristow -
Raffi Enficiaud -
Robert Ramey -
Stefan Seefeld