Re: [boost] [git] [conversion] Schedule and remaining showstoppers?

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Daniel James Sent: Thursday, October 24, 2013 9:01 AM To: boost@lists.boost.org Subject: Re: [boost] [git] [conversion] Schedule and remaining showstoppers?

On 24 October 2013 02:54, Dave Abrahams wrote:

...

on Tue Oct 22 2013, "Paul A. Bristow" wrote:

...

Will this also mean that the very many links in docs to Trac #1234 fixed items will still work without any changes?

Please show me an example of such a link.

There are lots of such links in the release notes, e.g. in:

http://www.boost.org/users/history/version_1_54_0.html

Do a text search for #6999, #8421.

And there are lots more tickets that *should* also be recorded in their individual docs. Boost.Math is trying to set a good example :-) In Quickbook, the Trac item is linked thus, for example: * Fixed PGI compilation issue [@https://svn.boost.org/trac/boost/ticket/8333 #8333]. And users can quickly see what is work-in-progress thus: Currently open bug reports can be viewed [@https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=reopened&component=math&c ol=id&col=summary&col=status&col=type&col=milestone&col=component&order=priority here].

They will work fine as long as we keep trac running. AFAIK there are no plans to turn it off (but maybe should prevent the creation of new tickets?).

So what would replace this very valuable function?

But if we ever turn it off, I'm sure we'll set something up to maintain the links.

The implicit links in commit logs won't work on github (e.g. trac converts #6999 to a ticket link,

So these Trac #1234 links will still work as before?

r83728 to a link to a changeset, I don't think github offers a way to do that), but since every revision should include a subversion commit number it will be pretty easy to find the changeset on trac where everything will be linked. We could possibly set up our own git viewer to manage that.

I'm reassured by this, but feel that some Trac-like system is very valuable, both for users and developers, so it remains a long-term must-have. Bugs and enhancements are the *first* things that people will be tackling after conversion to GIT (not new libraries at first), so it would be really good if we still had a way of handling the recording of info about the work on them. So (to start with) do we just carry on using Trac as before? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com