Re: [boost] [trac] Boost v1.64 in the milestones?

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.
>>>>
>>>>          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
>