Re: [boost] shutdown ticket-system on svn.boost.org

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