Le 17/12/2016 à 18:51, Stefan Seefeld a écrit :
On 17.12.2016 12:15, Paul A. Bristow wrote:
I am also totally fine with Trac, and it contains history that must not be lost.
OK, so let me retract a little: if it were up to me I would *freeze* the state of svn.boost.org, i.e. only allow those modifications that involve migrating content over to github, but not new content.
I believe you, but that's not the point ! :-) We have migrated our repositories to github, so we should use the *integrated* tools, rather than dispersing ourselves onto a lot of different infrastructure, which only increases the work and is prone of content getting out-of-sync. (As a point in case: look at the state of the (trac) wiki, which still refers to the svn->git migration as a future project.)
If it was up to me I would establish a deadline for shutting down the entire svn.boost.org site and then work hard to migrate the remaining useful bits over to github.com/boostorg.
Stefan
I'd think so too, especially since there are currently issues on both sites, which imo is rather confusing.
In theory I agree, but we need to be sure that GitHub does provide at least what we have from Trac ( I don't know how to use it for one), or decide what from Trac we can live without.
We also need to migrate the history from Trac, IMO. It may be history but it is still invaluable.
I'm afraid of making this so complicated that it won't get done. The Boost community seems to be so font on tools that it appears to spend far more time and energy on discussing those rather than working on its libraries. (At least that's the impression one gets from watching the mailing list.)
By making everything modular, we gain a lot but we lost indeed some federative decision on this kind of topics.
As I have said before, I'd really live it to the individual projects what tools they use (Boost.Python has moved to its github tracker, and no new issues on trac are allowed.) so all that remains to be done for Boost as a whole is a little bit of coordination, which I think is entirely possible with the tools github offers. (Hell, if I look at the state of the original wiki I'm thinking that it can't get worse than it currently is.)
One thing I am not sure about with GitHub is that, sometime it happens that a bug bounces from one project to another (eg. from boost.test to boost.config ... and then to boost.test again). This is rare, but this is right now just a matter of 1 operation in trac.
Perhaps we need something fancier like this ZenHub? (though at a glance it seems to have some very pretty features that don't look very useful to us as Boost?)
I'm again not sure who "us" is. There are tons of tools that can be integrated into github. Why not letting each project pick what they need and move on ?
Just fyi. there's a scrum plugin for github if the issue tracker is not enough: https://www.zenhub.com/ That integrates throuh a plugin into github and extends what you can do with the issues. But someone knowledgeable needs to sort it all out - including educating users.
Does anyone inside Boost use scrum or even just agile, and would benefit from tools like the above ? It would surprise me if that was the case.
I use Atlassian Jira, if it was only me, I would move GitHub issue tracking to Jira :) (Jira has a trac import as well) I administrate a Jira instance for 200 users, it is complete, sometimes difficult to use for some... it is a tool, it needs to be learned a bit. Also, I believe that boost.org can benefit from a free license of Jira.
Volunteers?
Paul
Not me :) Right now, I *just* would like to have 1.64 in the milestones :)
Best, Stefan