Currently the issue tracker is somewhat nicely integrated with SVN, what are we doing for issue tracking short/medium/long term? Apologies if this has been covered already, John.
On Mon, Dec 17, 2012 at 4:52 AM, John Maddock <boost.regex@virgin.net> wrote:
Currently the issue tracker is somewhat nicely integrated with SVN, what are we doing for issue tracking short/medium/long term?
Apologies if this has been covered already, John.
It hasn't been covered, and certainly merits a FAQ entry at the least. I'm pretty sure we are keeping the same trac, but we need Dave or someone else could fill in the details. --Beman
Beman Dawes wrote:
On Mon, Dec 17, 2012 at 4:52 AM, John Maddock wrote:
Currently the issue tracker is somewhat nicely integrated with SVN, what are we doing for issue tracking short/medium/long term?
Apologies if this has been covered already, John.
It hasn't been covered, and certainly merits a FAQ entry at the least.
I'm pretty sure we are keeping the same trac, but we need Dave or someone else could fill in the details.
Why not switch to the GitHub issue tracker? That should be nicely integrated with Git. -Julian
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Julian Gonggrijp Sent: Monday, December 17, 2012 6:28 PM To: boost@lists.boost.org Subject: Re: [boost] [GIT] What happens to the Trac?
Beman Dawes wrote:
On Mon, Dec 17, 2012 at 4:52 AM, John Maddock wrote:
Currently the issue tracker is somewhat nicely integrated with SVN, what are we doing for issue tracking short/medium/long term?
Apologies if this has been covered already, John.
It hasn't been covered, and certainly merits a FAQ entry at the least.
I'm pretty sure we are keeping the same trac, but we need Dave or someone else could fill in the details.
Why not switch to the GitHub issue tracker? That should be nicely integrated with Git.
I'm sure we can handle GitHub issue tracker, but if we can't maintain or automatically convert the existing docs links (Boost.Math docs history section for example has very many links like https://svn.boost.org/trac/boost/ticket/7177 for Trac items that were reported and fixed) then I'm sure I won't be the only person most upset ;-) Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
on Mon Dec 17 2012, Julian Gonggrijp <j.gonggrijp-AT-gmail.com> wrote:
Beman Dawes wrote:
On Mon, Dec 17, 2012 at 4:52 AM, John Maddock wrote:
Currently the issue tracker is somewhat nicely integrated with SVN, what are we doing for issue tracking short/medium/long term?
Apologies if this has been covered already, John.
It hasn't been covered, and certainly merits a FAQ entry at the least.
I'm pretty sure we are keeping the same trac, but we need Dave or someone else could fill in the details.
Why not switch to the GitHub issue tracker? That should be nicely integrated with Git.
The most obvious reasons: 1. We shouldn't make too many changes all at once 2. Existing links and references in commit messages would all break 3. Someone would need to import all the Trac issues into the GH tracker 4. There's actually one tracker per repository, which potentially complicates the transition a lot. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
Dave Abrahams wrote:
on Mon Dec 17 2012, Julian Gonggrijp wrote:
Why not switch to the GitHub issue tracker? That should be nicely integrated with Git.
The most obvious reasons:
1. We shouldn't make too many changes all at once
2. Existing links and references in commit messages would all break
3. Someone would need to import all the Trac issues into the GH tracker
4. There's actually one tracker per repository, which potentially complicates the transition a lot.
All valid points, but what's wrong with keeping trac for the old issues while requesting (or perhaps just encouraging, initially) that people submit new issues to the GitHub tracker?
On Mon, Dec 17, 2012 at 11:30 PM, Julian Gonggrijp <j.gonggrijp@gmail.com> wrote:
All valid points, but what's wrong with keeping trac for the old issues while requesting (or perhaps just encouraging, initially) that people submit new issues to the GitHub tracker?
I would very much prefer to have a single tracker to work with. What's the advantage of using GitHub compared to Trac?
On 17/12/12 20:37, Andrey Semashev wrote:
On Mon, Dec 17, 2012 at 11:30 PM, Julian Gonggrijp <j.gonggrijp@gmail.com> wrote:
All valid points, but what's wrong with keeping trac for the old issues while requesting (or perhaps just encouraging, initially) that people submit new issues to the GitHub tracker?
I would very much prefer to have a single tracker to work with. What's the advantage of using GitHub compared to Trac?
Easy integration. Then again neither Trac nor the Github issue systems are great bug reporting and tracking tools.
Mathias Gaunard wrote:
On 17/12/12 20:37, Andrey Semashev wrote:
On Mon, Dec 17, 2012 at 11:30 PM, Julian Gonggrijp <j.gonggrijp@gmail.com> wrote:
All valid points, but what's wrong with keeping trac for the old issues while requesting (or perhaps just encouraging, initially) that people submit new issues to the GitHub tracker?
I would very much prefer to have a single tracker to work with. What's the advantage of using GitHub compared to Trac?
Easy integration.
Then again neither Trac nor the Github issue systems are great bug reporting and tracking tools.
Hmmmm - I've always thought Trac was great. It has some minor annoyances - it slows down, but in general I think its just great from a user(me) point of view. But I'm not married to it. In general, I think the Boost Steering Commity - BS commitee for short - making good decisions here. a) One thing at a time - if that's possible i) moving to GIT ii) testing - separate issue. iii) issue tracking - separate issue iv) considering CMake - separate issue I've been using SVN and GIT and I though I don't have a huge preference, I see that GIT will be an improvement and will scale better. I would like to see the next thing - the testing - tweaked to make the default that a "trunk/expermental" library be tested against the the "next release" - that is the current release branch. I don't think this would be particularly disruptive change and I think it would have a number of benefits. I would like to personally thank the BS commitee for taking on this thankless task. It's a huge pain and they are going to get a lot of grief for it - but we really need to move on. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 17/12/12 23:03, Robert Ramey wrote:
Hmmmm - I've always thought Trac was great. It has some minor annoyances - it slows down, but in general I think its just great from a user(me) point of view.
I was thinking it could be a good idea to let maintainers use the tool they're most comfortable with, but then lack of consistency might be disconcerting to external users. I've always found that Bugzilla was much more powerful than any other tool, for example, but is also a bit more complicated.
On Mon, Dec 17, 2012 at 4:16 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
On 17/12/12 23:03, Robert Ramey wrote:
Hmmmm - I've always thought Trac was great. It has some minor
annoyances - it slows down, but in general I think its just great from a user(me) point of view.
I was thinking it could be a good idea to let maintainers use the tool they're most comfortable with, but then lack of consistency might be disconcerting to external users.
As a release manager I can say that I would much rather have a single consolidated bug database. As otherwise it would be a huge pain to get any idea of the state of libraries for a release. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On 12/17/2012 2:20 PM, Rene Rivera wrote:
As a release manager I can say that I would much rather have a single consolidated bug database. As otherwise it would be a huge pain to get any idea of the state of libraries for a release.
+1 -- Eric Niebler BoostPro Computing http://www.boostpro.com
on Mon Dec 17 2012, Eric Niebler <eric-AT-boostpro.com> wrote:
On 12/17/2012 2:20 PM, Rene Rivera wrote:
As a release manager I can say that I would much rather have a single consolidated bug database. As otherwise it would be a huge pain to get any idea of the state of libraries for a release.
+1
So there are a number of unresolved issues with using multiple trackers, and we shouldn't even think of dividing up our system until and unless we have a resolution. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
on Mon Dec 17 2012, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
On 17/12/12 23:03, Robert Ramey wrote:
Hmmmm - I've always thought Trac was great. It has some minor annoyances - it slows down, but in general I think its just great from a user(me) point of view.
I was thinking it could be a good idea to let maintainers use the tool they're most comfortable with, but then lack of consistency might be disconcerting to external users.
Maybe. Regardless, I request that we take up the topic of bug tracking systems after the transition to Git is complete. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
On Dec 17, 2012, at 2:24 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Mon Dec 17 2012, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
On 17/12/12 23:03, Robert Ramey wrote:
Hmmmm - I've always thought Trac was great. It has some minor annoyances - it slows down, but in general I think its just great from a user(me) point of view.
I was thinking it could be a good idea to let maintainers use the tool they're most comfortable with, but then lack of consistency might be disconcerting to external users.
Maybe. Regardless, I request that we take up the topic of bug tracking systems after the transition to Git is complete.
+1e10 -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On Mon, Dec 17, 2012 at 5:42 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Dec 17, 2012, at 2:24 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Mon Dec 17 2012, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
On 17/12/12 23:03, Robert Ramey wrote:
Hmmmm - I've always thought Trac was great. It has some minor annoyances - it slows down, but in general I think its just great from a user(me) point of view.
I was thinking it could be a good idea to let maintainers use the tool they're most comfortable with, but then lack of consistency might be disconcerting to external users.
Maybe. Regardless, I request that we take up the topic of bug tracking systems after the transition to Git is complete.
+1e10
Strong agreement. The release managers have to get a new Git-based release system working, and are also deeply involved in getting Git-based testing working. Not to mention the Git and Modular Boost conversion itself. We need to get all that under our belt before worrying about the svn trac. --Beman
I've always found that Bugzilla was much more powerful than any other tool, for example, but is also a bit more complicated.
A bug tracking tool that is often used with git is redmine (with gitolite integration). I'm not sure it'd suit something as big as boost (bulk-editing a lot of tickets in the interface doesn't scale very well), but it's worth mentionning. Philippe
Andrey Semashev wrote:
On Mon, Dec 17, 2012 at 11:30 PM, Julian Gonggrijp wrote:
All valid points, but what's wrong with keeping trac for the old issues while requesting (or perhaps just encouraging, initially) that people submit new issues to the GitHub tracker?
I would very much prefer to have a single tracker to work with. What's the advantage of using GitHub compared to Trac?
I'm not aware of any clear benefits of one system over the other. However, this thread started with John's question regarding what will happen now that the integration between Trac and Subversion is going to loose its relevance. I thought switching to GitHub might be the most straightforward way to regain a similar level of integration between issue tracker and version control. -Julian
on Mon Dec 17 2012, Julian Gonggrijp <j.gonggrijp-AT-gmail.com> wrote:
Andrey Semashev wrote:
On Mon, Dec 17, 2012 at 11:30 PM, Julian Gonggrijp wrote:
All valid points, but what's wrong with keeping trac for the old issues while requesting (or perhaps just encouraging, initially) that people submit new issues to the GitHub tracker?
I would very much prefer to have a single tracker to work with. What's the advantage of using GitHub compared to Trac?
I'm not aware of any clear benefits of one system over the other. However, this thread started with John's question regarding what will happen now that the integration between Trac and Subversion is going to loose its relevance. I thought switching to GitHub might be the most straightforward way to regain a similar level of integration between issue tracker and version control.
It is more straightforward to go that way, but it's also more disruptive. One disruption at a time, please. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
On Mon, Dec 17, 2012 at 9:18 PM, Julian Gonggrijp <j.gonggrijp@gmail.com>wrote:
I'm not aware of any clear benefits of one system over the other.
As having used both I can say that GitHub tracker is very simple, to match most usage, while TRAC is certainly one of the most customizable of such tools, in particular to make custom work flows. Jira, Redmine, Phabricator (used by LLVM apparently?) are almost as configurable, not quite as much though, but also are more responsive. Anyway... I think Dave's points are a good summary of what I think. This is certainly not a good time to change of tracker. In particular knowing that github will easily work with TRAC. Joel Lamotte
on Mon Dec 17 2012, Julian Gonggrijp <j.gonggrijp-AT-gmail.com> wrote:
Dave Abrahams wrote:
on Mon Dec 17 2012, Julian Gonggrijp wrote:
Why not switch to the GitHub issue tracker? That should be nicely integrated with Git.
The most obvious reasons:
1. We shouldn't make too many changes all at once
2. Existing links and references in commit messages would all break
3. Someone would need to import all the Trac issues into the GH tracker
4. There's actually one tracker per repository, which potentially complicates the transition a lot.
All valid points, but what's wrong with keeping trac for the old issues while requesting (or perhaps just encouraging, initially) that people submit new issues to the GitHub tracker?
1. We shouldn't make too many changes all at once 2. Fragmentation -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
Dave Abrahams wrote:
on Mon Dec 17 2012, Julian Gonggrijp wrote:
All valid points, but what's wrong with keeping trac for the old issues while requesting (or perhaps just encouraging, initially) that people submit new issues to the GitHub tracker?
1. We shouldn't make too many changes all at once 2. Fragmentation
Every GitHub repo includes an issue tracker by default (this appears to be true of all current Boost repos as well). Users who don't know better will submit their issues there. Are you going to switch off the trackers for all GitHub repos (this seems to be possible) in order to stop them? If not, how do you plan to prevent the change and fragmentation? In the latter case, my suggestion to request or encourage that new issues be submitted to GitHub might actually help to reduce fragmentation. But I wouldn't necessarily object against closing the GitHub trackers either. -Julian
on Mon Dec 17 2012, Julian Gonggrijp <j.gonggrijp-AT-gmail.com> wrote:
Dave Abrahams wrote:
on Mon Dec 17 2012, Julian Gonggrijp wrote:
All valid points, but what's wrong with keeping trac for the old issues while requesting (or perhaps just encouraging, initially) that people submit new issues to the GitHub tracker?
1. We shouldn't make too many changes all at once 2. Fragmentation
Every GitHub repo includes an issue tracker by default (this appears to be true of all current Boost repos as well). Users who don't know better will submit their issues there. Are you going to switch off the trackers for all GitHub repos (this seems to be possible) in order to stop them?
Probably.
If not, how do you plan to prevent the change and fragmentation?
In the latter case, my suggestion to request or encourage that new issues be submitted to GitHub might actually help to reduce fragmentation. But I wouldn't necessarily object against closing the GitHub trackers either.
Those can always be opened later, but initially they should be closed. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
on Mon Dec 17 2012, Beman Dawes <bdawes-AT-acm.org> wrote:
On Mon, Dec 17, 2012 at 4:52 AM, John Maddock <boost.regex@virgin.net> wrote:
Currently the issue tracker is somewhat nicely integrated with SVN, what are we doing for issue tracking short/medium/long term?
Apologies if this has been covered already, John.
It hasn't been covered, and certainly merits a FAQ entry at the least.
I'm pretty sure we are keeping the same trac, but we need Dave or someone else could fill in the details.
We're keeping the same trac and there's a plugin for doing the integration with GitHub: https://github.com/davglass/github-trac -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
On 17/12/12 18:31, Dave Abrahams wrote:
on Mon Dec 17 2012, Beman Dawes<bdawes-AT-acm.org> wrote:
On Mon, Dec 17, 2012 at 4:52 AM, John Maddock<boost.regex@virgin.net> wrote:
Currently the issue tracker is somewhat nicely integrated with SVN, what are we doing for issue tracking short/medium/long term?
Apologies if this has been covered already, John.
It hasn't been covered, and certainly merits a FAQ entry at the least.
I'm pretty sure we are keeping the same trac, but we need Dave or someone else could fill in the details.
We're keeping the same trac and there's a plugin for doing the integration with GitHub: https://github.com/davglass/github-trac
+1
participants (14)
-
Andrey Semashev -
Beman Dawes -
Dave Abrahams -
Eric Niebler -
Jamie Allsop -
John Maddock -
Julian Gonggrijp -
Klaim - Joël Lamotte -
Marshall Clow -
Mathias Gaunard -
Paul A. Bristow -
Philippe Vaucher -
Rene Rivera -
Robert Ramey