On 2018-07-31 04:42 AM, Paul A. Bristow via Boost wrote:

+1 to closed for new issues - but preferably allow continued write for existing open issues, and keeping read access for all issues (so that links to issues in release notes still work).

Keeping the trac instance accessible "for the record" is certainly fine. But I'd keep it read-only, to encourage everyone to migrate to github. It's trivial to migrate open issues. Or do we want to wait another ten years before concluding the migration ? The same argument holds for the wiki, by the way: I suggest we make the trac wiki read-only, so whenever someone wants to add or change info, it should be seen as an invitation to migrate. A few years ago I have started to migrate a few pages to github. But as long as the trac wiki isn't read-only, this migration will never conclude... Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 2018-07-31 05:31 AM, Mateusz Loskot via Boost wrote:

On 31 July 2018 at 11:17, Stefan Seefeld via Boost wrote:

...

On 2018-07-31 04:42 AM, Paul A. Bristow via Boost wrote:

...

+1 to closed for new issues - but preferably allow continued write for existing open issues, and keeping read access for all issues (so that links to issues in release notes still work).

Keeping the trac instance accessible "for the record" is certainly fine. But I'd keep it read-only, to encourage everyone to migrate to github. It's trivial to migrate open issues. Do you mean Trac to GitHub migration, automated or manual?

Manual. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 7/31/18 6:29 AM, Vinnie Falco via Boost wrote:

On Mon, Jul 30, 2018 at 8:19 AM, Robert Ramey via Boost wrote:

...

Could we agree to stop using the Trac system?

What is "Trac?"

LOL, LOL, LOL, LOL, LOL, LOL, LOL I rest my case. Robert Ramey

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 31/07/2018 16:24, Robert Ramey via Boost wrote:

On 7/30/18 8:19 AM, Robert Ramey via Boost wrote:

...

Could we agree to stop using the Trac system?  The github issues/pr system is much more functional.  I propose we close the trac system to new issues - be of course leave it available for reference.

OK - looks like we have a pretty strong consensus here - especially for Boost.  I don't know what has to be done. I presume that the BOD could lean on those who have the power to make this happen.  Let's see what they can do!

Well.... I have admin access, but don't really know what I'm doing! I think it might be read only now for all except the admins.  Maybe someone can try it and see? John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

...

I think it might be read only now for all except the admins. Maybe someone can try it and see?

AFAICT, issues and wiki is read-only now. It seems to be possible though to delete wiki pages.

Ah, now removed. I've also reinstated the ability for authenticated users to modify tickets: so you can redirect to github and close them or whatever. Can you please check this doesn't let you create new tickets? Admins still can, but I'm not sure which option is enabling that :/ John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Boost - Dev mailing list wrote

...

...

I think it might be read only now for all except the admins. Maybe someone can try it and see?

AFAICT, issues and wiki is read-only now. It seems to be possible though to delete wiki pages.

Ah, now removed.

I've also reinstated the ability for authenticated users to modify tickets: so you can redirect to github and close them or whatever.

FYI, I've made an initial attempt to switch links on the website from Trac to GitHub: https://github.com/boostorg/website/pull/366 ----- -- Mateusz Loskot, http://mateusz.loskot.net -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

...

OK - looks like we have a pretty strong consensus here - especially for Boost. I don't know what has to be done. I presume that the BOD could lean on those who have the power to make this happen. Let's see what they can do!

While I agree about Trac, is it really right to declare consensus after just two days?

To be fair, probably not.  On the other hand this issue keeps coming round and nothing ever gets done.... I'm happy to re-enable Trac if I've been over hasty, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

On 8/1/18 05:53, Mateusz Loskot via Boost wrote:

On 1 August 2018 at 14:48, John Maddock via Boost wrote:

...

...

...

OK - looks like we have a pretty strong consensus here - especially for Boost. I don't know what has to be done. I presume that the BOD could lean on those who have the power to make this happen. Let's see what they can do!

While I agree about Trac, is it really right to declare consensus after just two days?

To be fair, probably not. On the other hand this issue keeps coming round and nothing ever gets done....

Wasn't agreement to migrate to GitHub enough...

Not really. That was version control and to be historically correct, there wasn't "agreement" (o; -- Michael Caisse Ciere Consulting ciere.com

I have a bug to report to Boost.Graph for the proper placement of "boost/pending" headers. (I am submitting bugs to all repositories that have headers in boost/pending).

Github issues are disabled for this repository. Boost Trac has 134 open issues in it for this repository. There are some potentially serious issues like code regressions ( https://svn.boost.org/trac10/ticket/13332) open for many months without a reply.

I'm not sure if we still have an active maintainer for this library?

I no longer see a way to add new issues to Trac... was the change we discussed made?

Yes, submission of new issues is disabled, but old ones can still be edited.

If so, all github repositories must have issues enabled. Right now, I have no way to file an issue to Boost.Graph.

Now enabled.  Let me know if there are any other repositories in the same situation. Best, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

On 8/22/18 8:29 AM, Marc Glisse via Boost wrote:

On Wed, 22 Aug 2018, John Maddock via Boost wrote:

...

...

If so, all github repositories must have issues enabled.  Right now, I have no way to file an issue to Boost.Graph.

Now enabled.  Let me know if there are any other repositories in the same situation.

At least "algorithm" (I asked about algorithm and graph in July) and the super-project, which is were I would expect to report that issues are disabled for some subproject...

If graph needs a maintainer, I might be able to step up.  I have a more intuitive and extensible implementation nearing completion which I think people would take interest in.  Of course, I'm someone relatively out of the blue and that may not be OK, but it is something.

On 8/30/18 4:07 PM, Edward Diener via Boost wrote:

On 8/30/2018 1:42 PM, jrmarsha via Boost wrote:

...

On 8/22/18 8:29 AM, Marc Glisse via Boost wrote:

...

On Wed, 22 Aug 2018, John Maddock via Boost wrote:

...

...

If so, all github repositories must have issues enabled.  Right now, I have no way to file an issue to Boost.Graph.

Now enabled.  Let me know if there are any other repositories in the same situation.

At least "algorithm" (I asked about algorithm and graph in July) and the super-project, which is were I would expect to report that issues are disabled for some subproject...

If graph needs a maintainer, I might be able to step up.  I have a more intuitive and extensible implementation nearing completion which I think people would take interest in.  Of course, I'm someone relatively out of the blue and that may not be OK, but it is something.

I think that would be great.

It looks like there is quite a work backlog, and that Jeremiah Willcock is the primary person on this.  There are also pending pull requests.  What should I be doing?

On 8/30/18 13:41, jrmarsha via Boost wrote:

On 8/30/18 4:07 PM, Edward Diener via Boost wrote:

...

On 8/30/2018 1:42 PM, jrmarsha via Boost wrote:

...

On 8/22/18 8:29 AM, Marc Glisse via Boost wrote:

...

On Wed, 22 Aug 2018, John Maddock via Boost wrote:

...

...

If so, all github repositories must have issues enabled.  Right now, I have no way to file an issue to Boost.Graph.

Now enabled.  Let me know if there are any other repositories in the same situation.

At least "algorithm" (I asked about algorithm and graph in July) and the super-project, which is were I would expect to report that issues are disabled for some subproject...

If graph needs a maintainer, I might be able to step up.  I have a more intuitive and extensible implementation nearing completion which I think people would take interest in.  Of course, I'm someone relatively out of the blue and that may not be OK, but it is something.

I think that would be great.

It looks like there is quite a work backlog, and that Jeremiah Willcock is the primary person on this.  There are also pending pull requests.  What should I be doing?

I'm sending you a private email. michael -- Michael Caisse Ciere Consulting ciere.com

On 8/31/18 3:18 AM, John Maddock via Boost wrote:

...

...

...

If graph needs a maintainer, I might be able to step up.  I have a more intuitive and extensible implementation nearing completion which I think people would take interest in.  Of course, I'm someone relatively out of the blue and that may not be OK, but it is something.

I think that would be great.

It looks like there is quite a work backlog, and that Jeremiah Willcock is the primary person on this.  There are also pending pull requests.  What should I be doing?

Triage - I would suggest you make a list of all the things that are trivial-ish and good to go (or very nearly so) - then maybe get the CMT to sign off on them?  At some point someone will give you write access to that repro and just tell you to get on with it ;)

My guess is there's a lot of semi-trivial PR's which have merge conflicts (or at least conflict with each other), you may need to start a fork, merge all the low hanging fruit, and then submit one (or a few) big PR to do the integration testing.

HTH, John.

When I looked, there were already trivial pull requests pending.

On 8/31/18 11:22 AM, John Maddock via Boost wrote:

...

When I looked, there were already trivial pull requests pending.

OK good, what I'm saying is that in that case, most of the work is in triaging the PR's and issues, and then saying to the CMT - "here's the list of trivial ones that I've checked over, please merge for me, or give me permission to do so".

Making sure that there is good CI coverage is probably the first step though - once we have that it's much easier to be sure of the PR's.  Looks like at the moment there's travis support but it only does gcc-4.8/linux and no std variations or OS X support.  Also no appveyor support?  If you can file a PR (if there isn't one already) to bring those up to best-of-breed I think I might have permission to merge that for you.  Unfortunately activating appveyor isn't retro-active for existing PR's I believe (anyone confirm that?), so you might need to consolidate some of the existing PR's into perhaps a smaller number of new ones just to get CI coverage :(

HTH, John.

Then it sounds like those will work as good next steps.  I'll see what I can get done over the weekend.  I can help some, but boy am I not made of time.

On 9/1/18 12:02 AM, jrmarsha wrote:

On 8/31/18 11:22 AM, John Maddock via Boost wrote:

...

...

When I looked, there were already trivial pull requests pending.

OK good, what I'm saying is that in that case, most of the work is in triaging the PR's and issues, and then saying to the CMT - "here's the list of trivial ones that I've checked over, please merge for me, or give me permission to do so".

Making sure that there is good CI coverage is probably the first step though - once we have that it's much easier to be sure of the PR's.  Looks like at the moment there's travis support but it only does gcc-4.8/linux and no std variations or OS X support.  Also no appveyor support?  If you can file a PR (if there isn't one already) to bring those up to best-of-breed I think I might have permission to merge that for you. Unfortunately activating appveyor isn't retro-active for existing PR's I believe (anyone confirm that?), so you might need to consolidate some of the existing PR's into perhaps a smaller number of new ones just to get CI coverage :(

HTH, John.

I've made a first PR which deals with some of the first important bugfix PR's.  I'd like a review and pull into the devel branch.

https://github.com/boostorg/graph/pull/114

I'm getting into the weeds of how graph works.  I see why there are so many backlogged issues.  When I get through this first few batches of fixes, I will be starting a thread on replacing it.

Marshall Clow wrote:

When we have discussed this in the past, the next question is Who is going to migrate all the issues from Trac to Github?

I, for one, don't want any Trac issues migrated. Meaning, I really don't want them, not just could live without them. If migration occurs, I'd like to opt out of it.

On 8/1/18 10:46 AM, Marshall Clow via Boost wrote:

On Mon, Jul 30, 2018 at 8:19 AM, Robert Ramey via Boost < boost@lists.boost.org> wrote:

...

Could we agree to stop using the Trac system? The github issues/pr system is much more functional. I propose we close the trac system to new issues - be of course leave it available for reference.

Robert Ramey

When we have discussed this in the past, the next question is Who is going to migrate all the issues from Trac to Github?

And then people look at the sky, whistle, kick the ground, and wander off.

Who is volunteering to do that work?

No such work is necessary. The proposal is that they be left available but closed for new issues. This lets us have it both ways. Simple as that.

-- Marshall

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 2018-08-01 04:03 PM, Marshall Clow via Boost wrote:

On Wed, Aug 1, 2018 at 12:54 PM, Robert Ramey wrote:

...

No such work is necessary. The proposal is that they be left available but closed for new issues. This lets us have it both ways. Simple as that.

So you're fine with having two bug repositories. Then why close Trac?

That's quite a misrepresentation of what was discussed. The biggest issue with trac is that it's a single tracker for all of boost. If it were a bunch of trackers (one per library), each maintainer could choose his policy and we wouldn't have to have this conversation. I doubt anyone is "fine with two bug repositories". I'm sure everyone would prefer one (for his project). But unfortunately reality isn't that simple. That's no reason to stick with the status quo. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 8/1/18 1:03 PM, Marshall Clow via Boost wrote:

On Wed, Aug 1, 2018 at 12:54 PM, Robert Ramey wrote:

...

On 8/1/18 10:46 AM, Marshall Clow via Boost wrote:

...

On Mon, Jul 30, 2018 at 8:19 AM, Robert Ramey via Boost < boost@lists.boost.org> wrote:

Could we agree to stop using the Trac system? The github issues/pr system

...

is much more functional. I propose we close the trac system to new issues - be of course leave it available for reference.

Robert Ramey

When we have discussed this in the past, the next question is Who is going to migrate all the issues from Trac to Github?

And then people look at the sky, whistle, kick the ground, and wander off.

Who is volunteering to do that work?

No such work is necessary. The proposal is that they be left available but closed for new issues. This lets us have it both ways. Simple as that.

So you're fine with having two bug repositories. Then why close Trac?

I see 4 alternatives: a) stay with track and require developers to use trac and only trac b) require only github issues and convert all the old trac tickets to github. c) choose trac for all new issues but leave the old issues in trac so no one has to convert them d) let each library developer select which of the above he wants to do. I'm not adverse to b, c, or d. But the current setup of having two conflicting working systems is a burden on developers and adds no value. Robert Ramey

-- Marshall

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 2 August 2018 at 05:45, James E. King III via Boost wrote:

On Wed, Aug 1, 2018 at 4:47 PM Robert Ramey via Boost wrote:

...

I see 4 alternatives:

a) stay with track and require developers to use trac and only trac b) require only github issues and convert all the old trac tickets to github. c) choose trac for all new issues but leave the old issues in trac so no one has to convert them

d) let each library developer select which of the above he wants to do.

I'm not adverse to b, c, or d. But the current setup of having two conflicting working systems is a burden on developers and adds no value.

Robert Ramey

This issue has come up on the mailing list more than once and it was also discussed in the admin project as an issue. In short, the community is suffering from the "Too Many Chefs in the Kitchen" syndrome. There is a lot of discussion, with many opinions, but there is no authority body that can actually make a decision that drives the project towards improvement, and therefore things do not happen quickly (if at all).

Amen.

We will not always be able to make a decision that everyone can agree to, but decisions should satisfy a majority of participants and also help drive project quality and developer efficiency to improve. Standardizing on github for issues will do both.

As an observer of numerous discussions, I find process collecting agreements frustrating: - a proposal is discussed, 2, 3, 10, 15, ..? people participate - agreement is nearly completed - suddenly, an objection arrives from someone - whole agreement reached so far collapses - no one feels like challenging the objection with simple "you've been late", - steam is out, proposal dies The majority should be considered within those expressing their vote. I'm not aware of any formal voting scheme in Boost though.

If we leave existing issues in Trac then everyone should also commit to driving that backlog down to zero as a priority, and we should also measure this progress so that we can identify repositories that need ownership change to remain responsive to the community.

This is what I'm going to do for GIL: - not migrate of any Trac issues to GitHub, but work to clear them all as high priority task after Boost 1.68 is out. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

On 2018-08-02 07:35 AM, James E. King III via Boost wrote:

One thing Trac provides that github does not is a way to summarize the backlog (it has) for all components:

Why is that important ? (And besides, I'm sure something could be scripted using the github API, if someone really truly needed that info as a single list.) Stefan -- ...ich hab' noch einen Koffer in Berlin...

I'd being using boost for at least 6 years, and I don't remember any boost wiki. Do someone has access to check the request log of that wiki and confirm if there is traffic (aside from robots)? Maybe nobody is reading and that will make easier to decide to shut it down. Or maybe, that is the most visited page ever and it will not be a good idea. 2018-09-02 4:51 GMT-04:00 Raffi Enficiaud via Boost :

On 02.08.18 13:35, James E. King III via Boost wrote:

...

One thing Trac provides that github does not is a way to summarize the backlog (it has) for all components:

https://svn.boost.org/trac10/report/19?asc=1&page=1

Yes, and I like that feature somehow. Is there any mean on GitHub to populate release notes automatically from the issues and PRs that have been merged on master between 2 tags?

however the list of Maintainers in Trac is stale:

...

https://svn.boost.org/trac10/report/15

Trac has been used and (still is) as a wiki and ticket tracking system.

A wiki needs maintenance, this page you are pointing is outdated and not maintained, better removing it.

All in all, if we remove the ticketing system from trac making it read only, there is no point providing a wiki like system as well, especially if this one is not being maintained.

Relevant information for development and use of boost should go to the boost.org website, or to the boost superproject wiki on github (which has been partially done).

Raffi

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost

...

This issue has come up on the mailing list more than once and it was also discussed in the admin project as an issue. In short, the community is suffering from the "Too Many Chefs in the Kitchen" syndrome. There is a lot of discussion, with many opinions, but there is no authority body that can actually make a decision that drives the project towards improvement, and therefore things do not happen quickly (if at all).

Amen.

...

We will not always be able to make a decision that everyone can agree to, but decisions should satisfy a majority of participants and also help drive project quality and developer efficiency to improve. Standardizing on github for issues will do both.

As an observer of numerous discussions, I find process collecting agreements frustrating: - a proposal is discussed, 2, 3, 10, 15, ..? people participate - agreement is nearly completed - suddenly, an objection arrives from someone - whole agreement reached so far collapses - no one feels like challenging the objection with simple "you've been late", - steam is out, proposal dies

All the above is true. Things always arrive at a stalemate. This is the queue for the "Board of Directors to step in, review the conflicting proposals, make a decision and find someone willing and able to implement it. On hard part is accepting the fact that someone will leave unhappy. The other hard part is to avoid stepping into the it (the debate) themselves and try to craft something baroque which pleases everyone. Long story short: a) The BOD should review this chain. b) decide what to do c) line up someone to actually do it. d) See that it gets done. e) Announce that's done. f) Deflect, redirect or ignore the inevitable complaints g) Retreating back in their holes to ride out the shit storm of irrelevancy. h) until the next time an actual decision has to be made. The list will quiet down and move on ... until the next time. Robert Ramey Making Boost Great Again!

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Stefan Seefeld via Boost Sent: 02 August 2018 17:16 To: boost@lists.boost.org Cc: Stefan Seefeld Subject: Re: [boost] Trac

On 2018-08-02 12:02 PM, Robert Ramey via Boost wrote:

...

...

...

This issue has come up on the mailing list more than once and it was also discussed in the admin project as an issue. In short, the community is suffering from the "Too Many Chefs in the Kitchen" syndrome. There is a lot of discussion, with many opinions, but there is no authority body that can actually make a decision that drives the project towards improvement, and therefore things do not happen quickly (if at all).

Amen.

...

We will not always be able to make a decision that everyone can agree to, but decisions should satisfy a majority of participants and also help drive project quality and developer efficiency to improve.

I'd like to nuance a bit: This isn't a democracy. Not all participants on any given discussion are equal. There are always people who are more concerned by a proposed change than others, so their opinion should have greater weight.

...

...

...

Standardizing on github for issues will do both.

The biggest issue (as far as I'm concerned) with Trac is that it's monolithic, and thus, the question of whether or not to close it really concerns all Boost contributors. But as with other tools discussions, we really should get to a point where such questions can be discussed (and agreed upon !) per project. That will be much simpler, than trying to build consensus in the community as a whole.

But are we not closing it - only stopping NEW Trac entries. Existing items can be replied to and migrated, or not as maintainers decide. The rest is read-only - is it needs to be to keep the massive Boost history. Paul

On 1. Aug 2018, at 22:47, Robert Ramey via Boost wrote:

I see 4 alternatives:

a) stay with track and require developers to use trac and only trac b) require only github issues and convert all the old trac tickets to github. c) choose trac for all new issues but leave the old issues in trac so no one has to convert them

d) let each library developer select which of the above he wants to do.

e) Close trac for new tickets (as we are doing). Provide a script (like Roberts) that automatically transfers issues from trac to github for library maintainers that want to do that. Change the web pages everywhere to only point to github for issues. After a grace period of a few months, turn of trac. Maintainers who care about the old tickets will have moved them, others get rid of all the old and possibly outdated tickets and get a nice clean start.

On Fri, Sep 7, 2018 at 10:06 AM braden via Boost wrote:

Robert Ramey wrote

Perhaps wheels are already turning here and an update is in progress. If so, I apologize for harping.

https://github.com/boostorg/website/pull/366 -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net