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
On 30 July 2018 at 17:19, Robert Ramey via Boost <boost@lists.boost.org> wrote:
Could we agree to stop using the Trac system?
+1
I propose we close the trac system to new issues - be of course leave it available for reference.
+1 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Mateusz Loskot via Boost Sent: 30 July 2018 17:41 To: boost@lists.boost.org Cc: Mateusz Loskot Subject: Re: [boost] Trac
On 30 July 2018 at 17:19, Robert Ramey via Boost <boost@lists.boost.org> wrote:
Could we agree to stop using the Trac system?
+1
I propose we close the trac system to new issues - be of course leave it available for reference.
+1
+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). Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
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 31 July 2018 at 11:17, Stefan Seefeld via Boost <boost@lists.boost.org> 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? BTW, for GIL specifically, this should not be necessary as I'm in the middle of overhaul reviewing and closing *all* GIL issues dangling on Trac - to be completed once 1.68 release is out.
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.
+1 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On 2018-07-31 05:31 AM, Mateusz Loskot via Boost wrote:
On 31 July 2018 at 11:17, Stefan Seefeld via Boost <boost@lists.boost.org> 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 30. Jul 2018, at 17:19, 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
+2 also from me. Supporting two systems is a maintenance burden and confusing for people who want to contribute.
On 31 July 2018 at 15:29, Vinnie Falco via Boost <boost@lists.boost.org> 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?
What is "Trac?"
It is issues tracker, wiki and source browser integrated with SVN that Boost used to use, https://svn.boost.org/trac10/ Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
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 <boost@lists.boost.org> 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 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! Robert Ramey
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
On Tue, 31 Jul 2018, 19:19 John Maddock via Boost, <boost@lists.boost.org> wrote:
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?
AFAICT, issues and wiki is read-only now. It seems to be possible though to delete wiki pages. Mateusz Loskot, mateusz@loskot.net (Sent from mobile)
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
On Tue, 31 Jul 2018, 21:09 John Maddock via Boost, <boost@lists.boost.org> 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.
Yes, it is not possible to edit, delete wiki pages anymore. I've also reinstated the ability for authenticated users to modify
tickets: so you can redirect to github and close them or whatever.
Yes, authenticated users now can modify tickets. Can you please check this doesn't let you create new tickets? AFAICT, neither anonymous nor authenticated users can create new tickets. Mateusz Loskot, mateusz@loskot.net (Sent from mobile)
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
On Tue, Jul 31, 2018 at 5:24 PM, Robert Ramey via Boost <boost@lists.boost.org> 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!
While I agree about Trac, is it really right to declare consensus after just two days? -- Olaf
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 1 August 2018 at 14:48, John Maddock via Boost <boost@lists.boost.org> 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...
I'm happy to re-enable Trac if I've been over hasty, John.
Please, let's not do this. Let's kill Trac and get over it, and please let's not roll out a new never-ending thread. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On 8/1/18 05:53, Mateusz Loskot via Boost wrote:
On 1 August 2018 at 14:48, John Maddock via Boost <boost@lists.boost.org> 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
On Fri, Aug 3, 2018 at 1:51 PM Michael Caisse via Boost < boost@lists.boost.org> wrote:
On 8/1/18 05:53, Mateusz Loskot via Boost wrote:
On 1 August 2018 at 14:48, John Maddock via Boost <boost@lists.boost.org> 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 no longer see a way to add new issues to Trac... was the change we discussed made? If so, all github repositories must have issues enabled. Right now, I have no way to file an issue to Boost.Graph. - Jim
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 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... -- Marc Glisse
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/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.
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/2018 4:41 PM, 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?
First you need to get write access to the graph repository if you are going to be a maintainer. After that the PRs should get top priority. Following that you can look at any Issues and if you want to go back you can look at Trac bug reports for graph. Of course if things come up on this mailing list feel free to be as responsive and active as you like.
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
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. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
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.
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. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
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 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
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.
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.
On 7/31/18 11:54 PM, Olaf van der Spek via Boost wrote:
On Tue, Jul 31, 2018 at 5:24 PM, Robert Ramey via Boost <boost@lists.boost.org> 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!
While I agree about Trac, is it really right to declare consensus after just two days?
A good point. In the future, lets have a short "simmer down" period before implementing even obvious ideas. It won't cost anything and will give more people to note "surprises" Robert Ramey
On Mon, 30 Jul 2018, 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.
If you do that, please don't forget to enable issues on *all* github projects, including algorithm, graph, etc. -- Marc Glisse
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? -- Marshall
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 1 Aug 2018, at 20:28, Peter Dimov via Boost <boost@lists.boost.org> wrote:
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.
It make sense to let library maintainers select which issues to transfer from list of open Track issues for respective library. They may opt for all, none or anything in between. The script at https://github.com/robertoschwald/migrate-trac-issues-to-github can possibly be tweaked into something that migrate Trac issues selected by a library maintainer into issues in their respective GitHub repository. — Bjørn
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 Wed, Aug 1, 2018 at 12:54 PM, Robert Ramey <ramey@rrsd.com> 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? -- Marshall
On 2018-08-01 04:03 PM, Marshall Clow via Boost wrote:
On Wed, Aug 1, 2018 at 12:54 PM, Robert Ramey <ramey@rrsd.com> 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 <ramey@rrsd.com> 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 Wed, Aug 1, 2018 at 4:47 PM Robert Ramey via Boost <boost@lists.boost.org> 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). 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. My two cents on this one are that Trac is ancient and for the majority of repositories the contents are ignored. Having all the issues in github would help increase visibility. In many projects the backlogs are full of issues that have long since been fixed. We're using github now for our pull requests. Pull requests can automatically close issues when merged if the issues are in github. This does not happen if they are in Trac. Let's embrace the environment and provide some consistency to people that consume the project so they can use a tool they are already familiar with - a tool practically everyone else is using these days - and not a tool that's mostly ignored and mostly unknown to everyone else. 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. The backlog has been ignored in too many projects for too long. If we want to get issues into github it would be wise to first scrub what's in Trac and close out things already fixed or no longer applicable, then do the conversion. Either way, repository owners need to step up and manage their backlogs. To see one, insert your repository name below: https://svn.boost.org/trac10/query?status=!closed&component= <insert_name_here> Examples: https://svn.boost.org/trac10/query?status=!closed&component=system - 26 open issues https://svn.boost.org/trac10/query?status=!closed&component=thread - 62 open issues https://svn.boost.org/trac10/query?status=!closed&component=test - 31 open issues https://svn.boost.org/trac10/query?status=!closed&component=serialization - 76 open issues The vast majority of these issues haven't even been triaged yet and some are 10 years old. I mention these repositories because they are used quite often. In one case I've heard the owner has retired, but ownership hasn't been reassigned. In your own commercial projects would you let a backlog languish this way for your critical infrastructure? Why do we? Thanks, - Jim
On 2 August 2018 at 05:45, James E. King III via Boost <boost@lists.boost.org> wrote:
On Wed, Aug 1, 2018 at 4:47 PM Robert Ramey via Boost <boost@lists.boost.org> 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
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 however the list of Maintainers in Trac is stale: https://svn.boost.org/trac10/report/15 - Jim
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...
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:
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:
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
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 <boost@lists.boost.org>:
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:
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:
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
From: Damian Vicino via Boost Sent: Monday, September 3, 2018 7:14 AM To: boost@lists.boost.org Cc: Damian Vicino Subject: Re: [boost] Trac 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 <boost@lists.boost.org>:
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:
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:
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
Below are year to date values with bots excluded: /trac10/wiki/ModularBoost 18,278 /trac10/wiki/ReleasePractices/Procedures 11,621 /trac10/wiki/CMake 6,186 /trac10/wiki/DebuggerVisualizers 4,704 /trac10/wiki/BestPracticeHandbook 4,045 /trac10/wiki/LibrariesUnderConstruction 4,034 /trac10/wiki/SoC2017 3,372 /trac10/wiki/Git/GitHome 3,210 /trac10/wiki/Guidelines/WarningsGuidelines 3,185 /trac10/wiki/TryModBoost 3,039 /trac10/wiki/StartModMaint 2,764 /trac10/wiki/CommunityMaintenance 2,713 /trac10/wiki/ModBigPicture 2,414 /trac10/wiki/BoostSubversion 2,339 /trac10/wiki/WikiStart 2,193 /trac10/wiki/CMakeConfigAndBuild 2,169 /trac10/wiki/StartGitHub 1,910 /trac10/wiki/SoCPrevious 1,873 /trac10/wiki/CMakeModularizationStatus 1,727 /trac10/wiki/BoostDocs/PDF 1,530 /trac10/wiki/SoCSubmissionTemplate 1,024 There are another 150+ pages hit across the year with less than 100 views. Additionally, some general stats for the host: Average is ~40k unique clients per month, ~3,000,000 pages served resulting in around 18GB of traffic. 16GB of that traffic, across ~120k hits, is from bots. Normally 98% of those hits are direct hits or bookmarks (subversion traffic), roughly 47k a month from search results, and about 16k from external links including (for Aug 2018): - https://www.boost.org/users/download/ 1,007 - https://www.boost.org/wiki/ 966 - https://www.boost.org/doc/libs/1_67_0/doc/html/boost_asio/histor... 917 - https://www.boost.org/doc/libs/1_67_0/doc/html/thread/changes.ht... 617 - https://www.boost.org 596 - https://www.boost.org/doc/libs/1_67_0/libs/geometry/doc/html/geo... 495 - https://www.boost.org/wiki 475 - https://www.boost.org/doc/libs/1_67_0/doc/html/interprocess/ackn... 392 - https://www.boost.org/users/history/version_1_67_0.html 375 - https://www.boost.org/doc/libs/1_67_0/doc/html/container/release... 342 Hope that helps paint a picture. If not, or are there additional questions, feel free to let me know. Thanks, Brad Johnson Ciere Consulting
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!
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.
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.
"willing to implement it" isn't enough, if a given change affects maintenance. The people concerned are the contributors to any given project, so they should decide (again, per project), not any "board of directors". Stefan -- ...ich hab' noch einen Koffer in Berlin...
-----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 <boost@lists.boost.org> 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.
Robert Ramey 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.
As of this writing, the "Reporting and Fixing Bugs" link on the right side of the boost.org main page directs to a page that further directs bug reporters to Trac. Since Trac has been disabled, that link now serves a page with a "permission denied" message. Now, as a Boost user, I fully support the concept of using a bug tracking system that lives close to the code and will be visible to and actively used by Boost developers. I make that remark to note that this posting should not be taken as a criticism of the actions taken so far. But the current state of affairs with regard to directing users who'd like to file bugs to the right spot is not a great look. Perhaps wheels are already turning here and an update is in progress. If so, I apologize for harping. ----- Braden McDaniel braden@endoframe.com -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html
On Fri, Sep 7, 2018 at 10:06 AM braden via Boost <boost@lists.boost.org> 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
participants (21)
-
Bjørn Roald -
Brad Johnson -
braden -
Damian Vicino -
Edward Diener -
Hans Dembinski -
James E. King III -
John Maddock -
jrmarsha -
Marc Glisse -
Marshall Clow -
Mateusz Loskot -
Michael Caisse -
Olaf van der Spek -
Paul A. Bristow -
Peter Dimov -
Raffi Enficiaud -
Rene Rivera -
Robert Ramey -
Stefan Seefeld -
Vinnie Falco