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