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

Subject: Re: [boost] shutdown ticket-system on svn.boost.org
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2017-01-13 11:38:15

Le 13/01/2017 à 13:12, Paul A. Bristow a écrit :
>
>
>> -----Original Message-----
>> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Stefan Seefeld
>> Sent: 12 January 2017 22:09
>> To: boost_at_[hidden]
>> 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_at_[hidden]>
>>> 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-issues

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