Subject: Re: [boost] [trac] Boost v1.64 in the milestones?
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2016-12-17 13:21:54
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.
>>> 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.
Not me :) Right now, I *just* would like to have 1.64 in the milestones :)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk