On 17.12.2016 05:34, Raffi Enficiaud wrote:

Le 16/12/2016 à 21:21, Stefan Seefeld a écrit :

...

On 16.12.2016 15:07, Raffi Enficiaud wrote:

...

Dear all,

Since 1.63 is (almost) out, would it be possible to have 1.64 in the milestones of trac?

Wouldn't it be better to use the appropriate github issue tracker for this ?

I am totally fine with trac TBH.

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 -- ...ich hab' noch einen Koffer in Berlin...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Klemens Morgenstern Sent: 17 December 2016 13:25 To: boost@lists.boost.org Subject: Re: [boost] [trac] Boost v1.64 in the milestones?

Am 17.12.2016 um 14:08 schrieb Stefan Seefeld:

...

On 17.12.2016 05:34, Raffi Enficiaud wrote:

...

Le 16/12/2016 à 21:21, Stefan Seefeld a écrit :

...

...

Dear all,

Since 1.63 is (almost) out, would it be possible to have 1.64 in the milestones of trac? Wouldn't it be better to use the appropriate github issue tracker for

On 16.12.2016 15:07, Raffi Enficiaud wrote: this ? I am totally fine with trac TBH.

I am also totally fine with Trac, and it contains history that must not be lost.

...

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

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. Volunteers? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

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

On 17.12.2016 14:22, Daniel James wrote:

On 17 December 2016 at 17:51, Stefan Seefeld wrote:

...

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

I generally agree with projects choosing their own tools, but from the user perspective, we really do need a single place for them to report bugs. Dealing with one bug reporting system is bad enough.

I partly agree, but again, this depends on lot on the project in question. For example, Boost.Python bugs are typically very self-contained, and Boost.Python users know the project and don't need to be routed through some official Boost (meta-)tracker. Other projects / modules may be less independent, so it might not always be obvious for users where to report issues. A toplevel page with some guidance would be very useful in any case, and perhaps even a "catch all" tracker for users who don't know where else to report the issue. (Though I figure that to be the exception rather than the rule.) Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 21.12.2016 04:41, Vladimir Prus wrote:

On 17-Dec-16 8:51 PM, Stefan Seefeld wrote:

...

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

Do you mean that Boost.Python component was removed?

Not quiet; there are still open issues that haven't been transferred to the new tracker.

Are users pointed to github issue tracker in a clear way?

The tracker component name is changed to clearly indicate that new issues ought to be submitted to the new tracker. (That's all a bit clumsy, but apparently there isn't a better way to do this. Go to https://svn.boost.org/trac/boost/newticket and look for Python issues. You'll see "Python USE GITHUB" or somesuch. Some other components do the same...) That was all Rene's doing as I have no admin access to the trac instance. Ask him for details.

I am considering doing same for Boost.Build, but guess it will be bad if people no longer can find 'build' under svn.boost.org with no explanation.

Yeah, the tracker should stay alive as long as there is non-migrated content. Note that I also started migrating wiki pages from svn.boost.org to https://github.com/boostorg/boost/wiki. But there is quite a lot, and I was doing it alone... Ideally, if other people help, we could complete the migration within a reasonable amount of time and effort, and thus get out of this state of limbo that we seem to have been in for years now (at least as far as the wiki is concerned).

Thanks, Volodya

Best, Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 22.12.2016 03:37, Raffi Enficiaud wrote:

Just for information:

- as of today 1.64 is still not appearing in trac :) just a kind reminder

As much as I'd like to see this happen (in the github tracker), I'm even more keen to see the 1.63 release making progress. :-) (I have pinged Rene about github.com/boostorg, whose 'boost' repo right now has no issue tracker activated. I suppose that would be the right place to start tracking new milestones...)

- cmake recently moved from mantis to gitlab and it worked quite well, but I do not think the effort was little: - Mantis was left read only (and it still is), - all non-closed issues have been migrated to gitlab and a banner has been added (resolution "moved" + some text)

Something like this would be good for us, too.

They wrote a dedicated converter, I believe this can be adapted to trac/github:

http://cmake.3232098.n2.nabble.com/Mantis-to-GitLab-converter-td7594051.html

On my side, I am perfectly fine with moving to some other thing, but since boost is an umbrella project, users should have one unique interface with the issue tracker. I do not know much about github, maybe it works as "components" for each issues, and each "component" being a project/repo of the umbrella. I believe this needs some investigations, I just played with the "project" feature, I do not think this is doing what is needed there.

I still don't think that Boost.Python users should submit issues into a shared "Boost issue tracker". I see little value in that, and a lot of inconvenience for Boost developers. (In fact, this monotonic approach has proven its impracticability for the last couple of years - it simply doesn't scale to the number of projects / modules / libraries / components that are currently part of Boost.

Funny thing, just to check that ppl are reading: I am able to create a project on the boost umbrella project.

Concerning the wiki of GitHub, I am really not sure I like it the way it is. The information is hard to read, maintain and organize there. To my opinion, it is really targeted to single pages.

Perhaps. But as long as we (the Boost community) spend so much effort arguing about tools and little on content, there is not much that will improve. It's the state Boost has been in for the last couple of years. Stefan -- ...ich hab' noch einen Koffer in Berlin...