Hello, I have sent the following to the Boost documentation list, but since this is of broader relevance I have been asked to resend it here... The content of https://svn.boost.org/trac/boost/ seems rather outdated, and it has been confusing me a number of times as it wasn't clear what is and what isn't up-to-date. * There is an entire section "Quick Access to the Boost Subversion Repository". Shouldn't that be removed entirely ? * The section "Git and Modular Boost" starts with "Boost is moving...". Isn't that conversion complete (and thus, shouldn't the docs state that clearly) ? * There are other seemingly outdated bits, but there are relatively minor... What I was actually trying to figure out is how / where to indicate that for Boost.Python I would like issues to be submitted with the respective github issue tracker, rather than the old Boost Trac instance. It's still not clear how to do that (as the Boost docs are again quite monolithic in this respect, i.e. don't allow a per-library policy). So if anyone has suggestions on where / how to express that, please let me know. Thanks ! Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 7/15/2015 1:59 PM, Stefan Seefeld wrote:
Hello,
I have sent the following to the Boost documentation list, but since this is of broader relevance I have been asked to resend it here...
The content of https://svn.boost.org/trac/boost/ seems rather outdated, and it has been confusing me a number of times as it wasn't clear what is and what isn't up-to-date.
* There is an entire section "Quick Access to the Boost Subversion Repository". Shouldn't that be removed entirely ?
* The section "Git and Modular Boost" starts with "Boost is moving...". Isn't that conversion complete (and thus, shouldn't the docs state that clearly) ?
* There are other seemingly outdated bits, but there are relatively minor...
What I was actually trying to figure out is how / where to indicate that for Boost.Python I would like issues to be submitted with the respective github issue tracker, rather than the old Boost Trac instance. It's still not clear how to do that (as the Boost docs are again quite monolithic in this respect, i.e. don't allow a per-library policy). So if anyone has suggestions on where / how to express that, please let me know.
There are qute a few current PRs against Boost.Python going back to January 2014 onward. Are you trying to discourage people from submitting PRs for Boost.Python ? The handling of these PRs would go a long way to encourage people to use Git rather than the Boost Trac system, if that is your intent.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Stefan Seefeld Sent: 15 July 2015 18:59 To: Boost mailing list; Boost Steering Committee Subject: [boost] svn.boost.org wiki
The content of https://svn.boost.org/trac/boost/ seems rather outdated, and it has been confusing me a number of times as it wasn't clear what is and what isn't up-to-date.
What I was actually trying to figure out is how / where to indicate that for Boost.Python I would like issues to be submitted with the respective github issue tracker, rather than the old Boost Trac instance. It's still not clear how to do that (as the Boost docs are again quite monolithic in this respect, i.e. don't allow a per-library policy). So if anyone has suggestions on where / how to express that, please let me know.
We've discussed replacing Trac but without agreement yet on what it should be. Reports on Github were negative enough for us not to move yet. But that doesn't stop you using it? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 16/07/15 04:55 AM, Paul A. Bristow wrote:
We've discussed replacing Trac but without agreement yet on what it should be.
Reports on Github were negative enough for us not to move yet.
But that doesn't stop you using it?
Well, the reason for my OP was that http://www.boost.org/development/bugs.html sends users with bug reports for all of Boost to Trac. It might be better to move that content to library-specific pages (where individual libraries could adjust this to whatever tools they use). (In addition I was hoping Trac could be configured to block certain submissions, or at least, send notification to library maintainers, but that is an entirely separate discussion...) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 15 Jul 2015 at 13:59, Stefan Seefeld wrote:
The content of https://svn.boost.org/trac/boost/ seems rather outdated, and it has been confusing me a number of times as it wasn't clear what is and what isn't up-to-date.
* There is an entire section "Quick Access to the Boost Subversion Repository". Shouldn't that be removed entirely ?
* The section "Git and Modular Boost" starts with "Boost is moving...". Isn't that conversion complete (and thus, shouldn't the docs state that clearly) ?
* There are other seemingly outdated bits, but there are relatively minor...
At least the wiki is easy for anybody with a login to update and change.
What I was actually trying to figure out is how / where to indicate that for Boost.Python I would like issues to be submitted with the respective github issue tracker, rather than the old Boost Trac instance. It's still not clear how to do that (as the Boost docs are again quite monolithic in this respect, i.e. don't allow a per-library policy). So if anyone has suggestions on where / how to express that, please let me know.
An upgrade of Trac to the latest version would give us Trac <=> Github issue integration so both trackers become synchronised and git commit messages are deeply integrated with both trackers. Trac has been able to do that for years now, but our Trac is very old. I failed to even do a trial run of such an upgrade due to nobody knowing who has the keys to the servers anymore. For your purposes, if I were you I'd not worry too much. You'll find users ignore your instructions anyway. Indeed, far too many issues are now reported on Stackoverflow, and nowhere else. I constantly miss bug reports on stackoverflow because SO won't reliably send me emails with my subscribed topics or keywords :( Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Niall Douglas Sent: 16 July 2015 11:22 To: boost@lists.boost.org Subject: Re: [boost] svn.boost.org wiki
On 15 Jul 2015 at 13:59, Stefan Seefeld wrote:
<snip>
An upgrade of Trac to the latest version would give us Trac <=> Github issue integration so both trackers become synchronised and git commit messages are deeply integrated with both trackers. Trac has been able to do that for years now, but our Trac is very old.
I feel this is very unfortunate. It would be easy to say "Start again with some new system" but it would be very sad if we lost all the history in Trac.
I failed to even do a trial run of such an upgrade due to nobody knowing who has the keys to the servers anymore.
Thanks for your effort so far trying this. How can we progress this? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 16 Jul 2015 at 15:40, Paul A. Bristow wrote:
An upgrade of Trac to the latest version would give us Trac <=> Github issue integration so both trackers become synchronised and git commit messages are deeply integrated with both trackers. Trac has been able to do that for years now, but our Trac is very old.
I feel this is very unfortunate.
It would be easy to say "Start again with some new system" but it would be very sad if we lost all the history in Trac.
Especially as upgrading Trac is trivially easy, I agree. If one were intending a future relocation of issue tracking from Trac to Github, it's also the easiest way of bridging between the two.
I failed to even do a trial run of such an upgrade due to nobody knowing who has the keys to the servers anymore.
Thanks for your effort so far trying this.
How can we progress this?
We need to find someone with root privs on the server hosting Trac. That person needs to do as root a trac-admin dump of the existing Trac install and send it to me. I've volunteered do a trial run upgrade of that Trac dump on a VM here locally and report back here and to the SC on how well it went. If it goes very well, we then schedule a weekend for Boost Trac to go down and I do the upgrade by repeating exactly my earlier steps. Be aware that as of today I am unemployed, and therefore have time to do things like Trac upgrades. But if no new remote work contracts turn up soon, the chances are by this time next month I'll have to relocate to our capital city for some on-site 6 month contract, and I'll have to rescind my offer to trial this upgrade as I suspect I will no longer have the free time. After all, it's a four hour daily commute from here to the capital. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
participants (4)
-
Edward Diener -
Niall Douglas -
Paul A. Bristow -
Stefan Seefeld