Hi, A few months ago there seemed to be plans to improve Trac. What's the status of those plans? Trac is still slow as hell. http://lists.boost.org/Archives/boost/2011/12/188639.php http://lists.boost.org/Archives/boost/2011/12/188937.php -- Olaf
On Sun, Feb 12, 2012 at 1:49 AM, Olaf van der Spek <ml@vdspek.org> wrote:
Hi,
A few months ago there seemed to be plans to improve Trac. What's the status of those plans? Trac is still slow as hell.
http://lists.boost.org/Archives/boost/2011/12/188639.php http://lists.boost.org/Archives/boost/2011/12/188937.php
Somebody? Who's responsible for Boost infrastructure? -- Olaf
On Thu, Feb 16, 2012 at 4:22 PM, Olaf van der Spek <ml@vdspek.org> wrote:
On Sun, Feb 12, 2012 at 1:49 AM, Olaf van der Spek <ml@vdspek.org> wrote:
Hi,
A few months ago there seemed to be plans to improve Trac. What's the status of those plans? Trac is still slow as hell.
http://lists.boost.org/Archives/boost/2011/12/188639.php http://lists.boost.org/Archives/boost/2011/12/188937.php
Somebody? Who's responsible for Boost infrastructure?
Nobody? I'm sure I'm not the only one that's affected by Trac's slowness. -- Olaf
on Wed Feb 29 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Feb 16, 2012 at 4:22 PM, Olaf van der Spek <ml@vdspek.org> wrote:
On Sun, Feb 12, 2012 at 1:49 AM, Olaf van der Spek <ml@vdspek.org> wrote:
Hi,
A few months ago there seemed to be plans to improve Trac. What's the status of those plans? Trac is still slow as hell.
http://lists.boost.org/Archives/boost/2011/12/188639.php http://lists.boost.org/Archives/boost/2011/12/188937.php
Somebody? Who's responsible for Boost infrastructure?
Nobody?
I'm sure I'm not the only one that's affected by Trac's slowness.
We *were* in communication with OSUOSL about providing more powerful hosting resources for Boost, but since our last communication with them was in December and we still haven't gotten a reply, I wonder if we should consider them a reliable resource. Indiana has been good to us, and maybe it's just a question of asking them to allocate more resources... -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Mar 1, 2012 at 1:25 AM, Dave Abrahams <dave@boostpro.com> wrote:
on Wed Feb 29 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Feb 16, 2012 at 4:22 PM, Olaf van der Spek <ml@vdspek.org> wrote:
On Sun, Feb 12, 2012 at 1:49 AM, Olaf van der Spek <ml@vdspek.org> wrote:
Hi,
A few months ago there seemed to be plans to improve Trac. What's the status of those plans? Trac is still slow as hell.
http://lists.boost.org/Archives/boost/2011/12/188639.php http://lists.boost.org/Archives/boost/2011/12/188937.php
Somebody? Who's responsible for Boost infrastructure?
Nobody?
I'm sure I'm not the only one that's affected by Trac's slowness.
We *were* in communication with OSUOSL about providing more powerful hosting resources for Boost, but since our last communication with them was in December and we still haven't gotten a reply, I wonder if we should consider them a reliable resource. Indiana has been good to us, and maybe it's just a question of asking them to allocate more resources...
Somebody? -- Olaf
On Thu, Mar 8, 2012 at 9:44 AM, Olaf van der Spek <ml@vdspek.org> wrote:
On Thu, Mar 1, 2012 at 1:25 AM, Dave Abrahams <dave@boostpro.com> wrote:
We *were* in communication with OSUOSL about providing more powerful
Somebody?
We are, slowly, working to get the OSUOSL system set up. But we at lest have the Boost VM running in their cluster. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On Thu, Mar 8, 2012 at 4:53 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Thu, Mar 8, 2012 at 9:44 AM, Olaf van der Spek <ml@vdspek.org> wrote:
On Thu, Mar 1, 2012 at 1:25 AM, Dave Abrahams <dave@boostpro.com> wrote:
We *were* in communication with OSUOSL about providing more powerful
Somebody?
We are, slowly, working to get the OSUOSL system set up. But we at lest have the Boost VM running in their cluster.
Good to hear. Who is we though? And why slowly? -- Olaf
On Thu, Mar 8, 2012 at 5:35 PM, Olaf van der Spek <ml@vdspek.org> wrote:
On Thu, Mar 8, 2012 at 4:53 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Thu, Mar 8, 2012 at 9:44 AM, Olaf van der Spek <ml@vdspek.org> wrote:
On Thu, Mar 1, 2012 at 1:25 AM, Dave Abrahams <dave@boostpro.com> wrote:
We *were* in communication with OSUOSL about providing more powerful
Somebody?
We are, slowly, working to get the OSUOSL system set up. But we at lest have the Boost VM running in their cluster.
Good to hear. Who is we though? And why slowly?
^ -- Olaf
on Thu Mar 08 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Mar 8, 2012 at 4:53 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Thu, Mar 8, 2012 at 9:44 AM, Olaf van der Spek <ml@vdspek.org> wrote:
On Thu, Mar 1, 2012 at 1:25 AM, Dave Abrahams <dave@boostpro.com> wrote:
We *were* in communication with OSUOSL about providing more powerful
Somebody?
We are, slowly, working to get the OSUOSL system set up. But we at lest have the Boost VM running in their cluster.
Good to hear. Who is we though? And why slowly?
These are good questions. Rene and I have been the primary points-of-contact with OSUOSL, and we're busy. It would be wonderful if some other qualified person wanted to take over pushing this transition forward. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Wed, Mar 14, 2012 at 11:30 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Thu Mar 08 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Mar 8, 2012 at 4:53 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Thu, Mar 8, 2012 at 9:44 AM, Olaf van der Spek <ml@vdspek.org> wrote:
On Thu, Mar 1, 2012 at 1:25 AM, Dave Abrahams <dave@boostpro.com> wrote:
We *were* in communication with OSUOSL about providing more powerful
Somebody?
We are, slowly, working to get the OSUOSL system set up. But we at lest have the Boost VM running in their cluster.
Good to hear. Who is we though? And why slowly?
These are good questions. Rene and I have been the primary points-of-contact with OSUOSL, and we're busy. It would be wonderful if some other qualified person wanted to take over pushing this transition forward.
I'd be happy to help out. Is there a concrete plan? -- Olaf
on Thu Mar 15 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Wed, Mar 14, 2012 at 11:30 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Thu Mar 08 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Mar 8, 2012 at 4:53 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Thu, Mar 8, 2012 at 9:44 AM, Olaf van der Spek <ml@vdspek.org> wrote:
On Thu, Mar 1, 2012 at 1:25 AM, Dave Abrahams <dave@boostpro.com> wrote:
We *were* in communication with OSUOSL about providing more powerful
Somebody?
We are, slowly, working to get the OSUOSL system set up. But we at lest have the Boost VM running in their cluster.
Good to hear. Who is we though? And why slowly?
These are good questions. Rene and I have been the primary points-of-contact with OSUOSL, and we're busy. It would be wonderful if some other qualified person wanted to take over pushing this transition forward.
I'd be happy to help out.
Is there a concrete plan?
Not a very concrete one. Someone needs to do some planning, too. IMHO, we should set up Redmine at OSUOSL and make a transition to that almost immediately, because the conversion can be pretty much automatic. Beman is on the warpath (with my support) to transition us to Git in the near future. It's not clear whether we will end up with a monolithic transition (https://github.com/ryppl/boost-history) as a first step, or whether we will go directly to a modularized setup (https://github.com/boost-lib/boost/tree/master/libs). That will require some work on the Redmine end, I expect. OSUOSL can probably help us with some of the Redmine database rewrites that will be required, but I am not sure of that. At that point we should probably also give each library its own Redmine project, or, if we are modularized at that point, possibly give library maintainers the option to use the GitHub issue tracker associated with the library's repository there. As far as I'm concerned, anyone around here who expresses willingness to make this transition happen (with help from others) and confidence in his/her abilities to do it has my blessing. We may want to take a quick vote in the steering committee to make sure the plan is "officially blessed." -Dave -- Dave Abrahams BoostPro Computing http://www.boostpro.com
I'd be happy to help out.
Is there a concrete plan?
Not a very concrete one. Someone needs to do some planning, too. IMHO, we should set up Redmine at OSUOSL and make a transition to that almost immediately, because the conversion can be pretty much automatic.
Has the decision to move to Redmine been made (already)? Last time some were arguing Trac might be 'fine'.
That will require some work on the Redmine end, I expect. OSUOSL can probably help us with some of the Redmine database rewrites that will be required, but I am not sure of that.
At that point we should probably also give each library its own Redmine project, or, if we are modularized at that point, possibly give library maintainers the option to use the GitHub issue tracker associated with the library's repository there.
Why not move to a GH tracker right away? Olaf
on Mon Mar 19 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
I'd be happy to help out.
Is there a concrete plan?
Not a very concrete one. Someone needs to do some planning, too. IMHO, we should set up Redmine at OSUOSL and make a transition to that almost immediately, because the conversion can be pretty much automatic.
Has the decision to move to Redmine been made (already)? Last time some were arguing Trac might be 'fine'.
We've also heard from people who say that they've never used a large Trac installation that wasn't slow. I guess the steering committee hasn't voted on this. If you want a formal decision before proceeding, please request that Beman take a vote in the steering committee.
That will require some work on the Redmine end, I expect. OSUOSL can probably help us with some of the Redmine database rewrites that will be required, but I am not sure of that.
At that point we should probably also give each library its own Redmine project, or, if we are modularized at that point, possibly give library maintainers the option to use the GitHub issue tracker associated with the library's repository there.
Why not move to a GH tracker right away?
The main reasons: 1. We don't know that it's possible to preserve all the information from Trac in such a conversion. 2. GH trackers are not well-suited to multi-project repositories. Until we are modularized IMO it doesn't make sense. 3. Redmine (with the appropriate plugin) supports code review, whereas GitHub only supports change review. That's a significant and problematic difference where the formal review process is concerned. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Mon, Mar 19, 2012 at 6:14 PM, Dave Abrahams <dave@boostpro.com> wrote:
We've also heard from people who say that they've never used a large Trac installation that wasn't slow. I guess the steering committee hasn't voted on this. If you want a formal decision before proceeding, please request that Beman take a vote in the steering committee.
I don't mind. Can the move be completed without formal decision? If not, now seems like the right time to make that decision. How should I proceed? Who manages Trac? IIRC there was also talk about moving to a new VM? Olaf
on Mon Mar 19 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Mon, Mar 19, 2012 at 6:14 PM, Dave Abrahams <dave@boostpro.com> wrote:
We've also heard from people who say that they've never used a large Trac installation that wasn't slow. I guess the steering committee hasn't voted on this. If you want a formal decision before proceeding, please request that Beman take a vote in the steering committee.
I don't mind. Can the move be completed without formal decision?
Probably, but to know that I think the steering committee would have to say "we decline to decide"... which is about the same as making a decision.
If not, now seems like the right time to make that decision.
How should I proceed?
Request that Beman take a vote in the steering committee, I guess.
Who manages Trac?
Dong-inn Kim at IU's OSL (Cc'd) holds the sysadmin keys. We have lots of people with admin privileges on the trac site itself.
IIRC there was also talk about moving to a new VM?
Yes; what's the question? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Mar 22, 2012 at 9:02 AM, Dave Abrahams <dave@boostpro.com> wrote:
on Mon Mar 19 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Mon, Mar 19, 2012 at 6:14 PM, Dave Abrahams <dave@boostpro.com> wrote: Who manages Trac?
Dong-inn Kim at IU's OSL (Cc'd) holds the sysadmin keys. We have lots of people with admin privileges on the trac site itself.
I can also do admin/root tasks on the web site. Not that I will have time this week.. But I might a little more next week onward. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On Thu, Mar 22, 2012 at 3:02 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Mon Mar 19 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Mon, Mar 19, 2012 at 6:14 PM, Dave Abrahams <dave@boostpro.com> wrote:
We've also heard from people who say that they've never used a large Trac installation that wasn't slow. I guess the steering committee hasn't voted on this. If you want a formal decision before proceeding, please request that Beman take a vote in the steering committee.
I don't mind. Can the move be completed without formal decision?
Probably, but to know that I think the steering committee would have to say "we decline to decide"... which is about the same as making a decision.
If not, now seems like the right time to make that decision.
How should I proceed?
Request that Beman take a vote in the steering committee, I guess.
Hi Beman, Trac (performance) isn't good, we'd like to replace it with Redmine. Is the steering committe ok with this? -- Olaf
On Thu, Mar 22, 2012 at 12:44 PM, Olaf van der Spek <ml@vdspek.org> wrote:
Hi Beman,
Trac (performance) isn't good, we'd like to replace it with Redmine. Is the steering committe ok with this?
The steering committee would need a short proposal document that lays out the motivation for a change, the pros and cons of Redmine vs Trac, and how the transition would be accomplished. Plus a few links to relevant info. That will give the SC something specific to vote on. Personally, Redmine seems a good choice, but I've a couple of concerns: IIUC, performance is a major motivation. A quick try with google found many assertions that Redmine was faster than Trac, but no actual performance measurements. Has performance actually been measured? I also came across a case where someone moved from Trac to Redmine, then moved back again a year later because they weren't familiar enough with Ruby on Rails, and that caused them admin problems. Is that also a likely problem for Boost? --Beman
On Fri, Mar 23, 2012 at 11:07 AM, Beman Dawes <bdawes@acm.org> wrote:
On Thu, Mar 22, 2012 at 12:44 PM, Olaf van der Spek <ml@vdspek.org> wrote:
Hi Beman,
Trac (performance) isn't good, we'd like to replace it with Redmine. Is the steering committe ok with this?
The steering committee would need a short proposal document that lays out the motivation for a change, the pros and cons of Redmine vs Trac, and how the transition would be accomplished. Plus a few links to relevant info. That will give the SC something specific to vote on.
Personally, Redmine seems a good choice, but I've a couple of concerns:
IIUC, performance is a major motivation. A quick try with google found many assertions that Redmine was faster than Trac, but no actual performance measurements. Has performance actually been measured?
I also came across a case where someone moved from Trac to Redmine, then moved back again a year later because they weren't familiar enough with Ruby on Rails, and that caused them admin problems. Is that also a likely problem for Boost?
Dave, Rene, What has been done already? Performance analysis of current situation? What other issue tracker improvement requests exist? IIRC Dave came up with Redmine. Was this discussed already? Might another tracker / solution be better? -- Olaf
On Fri, Mar 23, 2012 at 1:18 PM, Olaf van der Spek <ml@vdspek.org> wrote:
On Fri, Mar 23, 2012 at 11:07 AM, Beman Dawes <bdawes@acm.org> wrote:
On Thu, Mar 22, 2012 at 12:44 PM, Olaf van der Spek <ml@vdspek.org> wrote:
Hi Beman,
Trac (performance) isn't good, we'd like to replace it with Redmine. Is the steering committe ok with this?
The steering committee would need a short proposal document that lays out the motivation for a change, the pros and cons of Redmine vs Trac, and how the transition would be accomplished. Plus a few links to relevant info. That will give the SC something specific to vote on.
Personally, Redmine seems a good choice, but I've a couple of concerns:
IIUC, performance is a major motivation. A quick try with google found many assertions that Redmine was faster than Trac, but no actual performance measurements. Has performance actually been measured?
I also came across a case where someone moved from Trac to Redmine, then moved back again a year later because they weren't familiar enough with Ruby on Rails, and that caused them admin problems. Is that also a likely problem for Boost?
Dave, Rene,
What has been done already? Performance analysis of current situation? What other issue tracker improvement requests exist? IIRC Dave came up with Redmine. Was this discussed already? Might another tracker / solution be better?
I don't mind working on this, but I do need some starting pointers. Please... -- Olaf
On Wed, Mar 28, 2012 at 11:35 AM, Olaf van der Spek <ml@vdspek.org> wrote:
On Fri, Mar 23, 2012 at 1:18 PM, Olaf van der Spek <ml@vdspek.org> wrote:
On Fri, Mar 23, 2012 at 11:07 AM, Beman Dawes <bdawes@acm.org> wrote:
On Thu, Mar 22, 2012 at 12:44 PM, Olaf van der Spek <ml@vdspek.org> wrote:
Hi Beman,
Trac (performance) isn't good, we'd like to replace it with Redmine. Is the steering committe ok with this?
The steering committee would need a short proposal document that lays out the motivation for a change, the pros and cons of Redmine vs Trac, and how the transition would be accomplished. Plus a few links to relevant info. That will give the SC something specific to vote on.
Personally, Redmine seems a good choice, but I've a couple of concerns:
IIUC, performance is a major motivation. A quick try with google found many assertions that Redmine was faster than Trac, but no actual performance measurements. Has performance actually been measured?
I also came across a case where someone moved from Trac to Redmine, then moved back again a year later because they weren't familiar enough with Ruby on Rails, and that caused them admin problems. Is that also a likely problem for Boost?
Dave, Rene,
What has been done already? Performance analysis of current situation? What other issue tracker improvement requests exist? IIRC Dave came up with Redmine. Was this discussed already? Might another tracker / solution be better?
I don't mind working on this, but I do need some starting pointers. Please...
The bug tracker isn't the only thing that's slow... -- Olaf
on Fri Mar 23 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
Dave, Rene,
What has been done already? Performance analysis of current situation? What other issue tracker improvement requests exist? IIRC Dave came up with Redmine. Was this discussed already? Might another tracker / solution be better?
I'm sorry, I thought I already posted this reply but I don't see it here. We've heard from people who say they've never seen a Trac installation with good performance. However... IMO it will not be productive to go through an extensive analysis of the current performance, a review of other issue tracker improvement requests, or a survey of other tracker technologies. What we need is improved performance, ASAP. The only way to know how Redmine will perform in practice for Boost is to try it. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Sat, Apr 7, 2012 at 3:19 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Fri Mar 23 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
Dave, Rene,
What has been done already? Performance analysis of current situation? What other issue tracker improvement requests exist? IIRC Dave came up with Redmine. Was this discussed already? Might another tracker / solution be better?
I'm sorry, I thought I already posted this reply but I don't see it here.
We've heard from people who say they've never seen a Trac installation with good performance. However...
IMO it will not be productive to go through an extensive analysis of the current performance, a review of other issue tracker improvement requests, or a survey of other tracker technologies. What we need is improved performance, ASAP. The only way to know how Redmine will perform in practice for Boost is to try it.
Beman, Is this ok with the steering committee? -- Olaf
AMDG On 04/08/2012 09:55 AM, Olaf van der Spek wrote:
On Sat, Apr 7, 2012 at 3:19 PM, Dave Abrahams <dave@boostpro.com> wrote:
I'm sorry, I thought I already posted this reply but I don't see it here.
We've heard from people who say they've never seen a Trac installation with good performance. However...
IMO it will not be productive to go through an extensive analysis of the current performance, a review of other issue tracker improvement requests, or a survey of other tracker technologies. What we need is improved performance, ASAP. The only way to know how Redmine will perform in practice for Boost is to try it.
Beman,
Is this ok with the steering committee?
I can't speak for anyone else, but throwing something in and hoping it helps is most certainly not okay with me. In Christ, Steven Watanabe
on Sun Apr 08 2012, Steven Watanabe <watanabesj-AT-gmail.com> wrote:
AMDG
On 04/08/2012 09:55 AM, Olaf van der Spek wrote:
On Sat, Apr 7, 2012 at 3:19 PM, Dave Abrahams <dave@boostpro.com> wrote:
I'm sorry, I thought I already posted this reply but I don't see it here.
We've heard from people who say they've never seen a Trac installation with good performance. However...
IMO it will not be productive to go through an extensive analysis of the current performance, a review of other issue tracker improvement requests, or a survey of other tracker technologies. What we need is improved performance, ASAP. The only way to know how Redmine will perform in practice for Boost is to try it.
Beman,
Is this ok with the steering committee?
I can't speak for anyone else, but throwing something in and hoping it helps is most certainly not okay with me.
What does "throwing something in" mean? What better way is there to find out if performance is better than to migrate the data and exercise the site? If you have other suggestions, please make them. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Dave Abrahams wrote:
on Sun Apr 08 2012, Steven Watanabe <watanabesj-AT-gmail.com> wrote:
AMDG
On 04/08/2012 09:55 AM, Olaf van der Spek wrote:
On Sat, Apr 7, 2012 at 3:19 PM, Dave Abrahams <dave@boostpro.com> wrote:
I'm sorry, I thought I already posted this reply but I don't see it here.
We've heard from people who say they've never seen a Trac installation with good performance. However...
IMO it will not be productive to go through an extensive analysis of the current performance, a review of other issue tracker improvement requests, or a survey of other tracker technologies. What we need is improved performance, ASAP. The only way to know how Redmine will perform in practice for Boost is to try it.
Beman,
Is this ok with the steering committee?
I can't speak for anyone else, but throwing something in and hoping it helps is most certainly not okay with me.
What does "throwing something in" mean?
What better way is there to find out if performance is better than to migrate the data and exercise the site? If you have other suggestions, please make them.
Hmm - what does "The only way to know Redmine will perform in practice for Boost is to try it." mean? It sounded like what was being proposed was not a test but rather just moving to something else "ASAP" I doubt anyone would object to some real test. But that's not so easy. I'm guessing that the performance is subtect to the size of the database and the configuration. So to it's hard to make a real test without migrating the whole trac history to the "other" system - whatever that might be. The proposal sounded like "let's just do it" which is what I believe raised concerns. Is it possible that the Trac is slow because of the hardware configuration it's being run on? Do we have any control over that? Note that Source Forge offers to run Trac systems for any library. I wonder what the performance would be if it were run there? Finally, maybe it's time to give up on the idea of a monolithic Trac system. Seems to me that letting each library have it's own Trac system would be a small first step in the direction of modularization as well as solving the performance issue. But then, it wouldn't even be a requirement that each library use the same Trac system. And it would be easy to test/experiment since any authors who are fed up with the current system could just migrate out to the one they prefer. So if some idea turns out to be a bad one, the damage will be limited to one library to be fixed up by the person who made the change. As far as I can see, the only thing lost by this idea would be the ability to easily re-assign tickets. This would be inconvenient, but seems a small price to pay. BTW I don't know this but I'm wonder if ASIO and Spirit don't already have their own systems for tracking bugs and enhancements. Robert Ramey
on Sun Apr 08 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Dave Abrahams wrote:
on Sun Apr 08 2012, Steven Watanabe <watanabesj-AT-gmail.com> wrote:
AMDG
On 04/08/2012 09:55 AM, Olaf van der Spek wrote:
On Sat, Apr 7, 2012 at 3:19 PM, Dave Abrahams <dave@boostpro.com> wrote:
I'm sorry, I thought I already posted this reply but I don't see it here.
We've heard from people who say they've never seen a Trac installation with good performance. However...
IMO it will not be productive to go through an extensive analysis of the current performance, a review of other issue tracker improvement requests, or a survey of other tracker technologies. What we need is improved performance, ASAP. The only way to know how Redmine will perform in practice for Boost is to try it.
Beman,
Is this ok with the steering committee?
I can't speak for anyone else, but throwing something in and hoping it helps is most certainly not okay with me.
What does "throwing something in" mean?
What better way is there to find out if performance is better than to migrate the data and exercise the site? If you have other suggestions, please make them.
Hmm - what does "The only way to know Redmine will perform in practice for Boost is to try it." mean?
It means... to try it.
It sounded like what was being proposed was not a test but rather just moving to something else "ASAP" I doubt anyone would object to some real test. But that's not so easy.
Really, it's pretty easy.
I'm guessing that the performance is subtect to the size of the database and the configuration. So to it's hard to make a real test without migrating the whole trac history
Exactly. And that's easy.
to the "other" system - whatever that might be. The proposal sounded like "let's just do it" which is what I believe raised concerns.
Obviously, let's just set it up and poke at it until you're satisfied.
Is it possible that the Trac is slow because of the hardware configuration it's being run on? Do we have any control over that? Note that Source Forge offers to run Trac systems for any library. I wonder what the performance would be if it were run there?
Finally, maybe it's time to give up on the idea of a monolithic Trac system. Seems to me that letting each library have it's own Trac system would be a small first step in the direction of modularization as well as solving the performance issue. But then, it wouldn't even be a requirement that each library use the same Trac system. And it would be easy to test/experiment since any authors who are fed up with the current system could just migrate out to the one they prefer. So if some idea turns out to be a bad one, the damage will be limited to one library to be fixed up by the person who made the change.
As far as I can see, the only thing lost by this idea would be the ability to easily re-assign tickets. This would be inconvenient, but seems a small price to pay. BTW I don't know this but I'm wonder if ASIO and Spirit don't already have their own systems for tracking bugs and enhancements.
The thing that's lost by this idea is any sense of being able to achieve a substantial speedup ASAP without lots of work, experimentation, etc. There's a script to convert Trac to Redmine. If it works and Redmine is fast enough, we're done solving the speedup problem. If not, consider alternatives. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Mon, Apr 9, 2012 at 11:49, Dave Abrahams <dave@boostpro.com> wrote:
The thing that's lost by this idea is any sense of being able to achieve a substantial speedup ASAP without lots of work, experimentation, etc. There's a script to convert Trac to Redmine. If it works and Redmine is fast enough, we're done solving the speedup problem. If not, consider alternatives.
Hi, I dont have an advice on this but I have just 3 infos about that that might be good to take into account : 1. I suspect that the conversion script will make the tickets exactly in the same configuration than in TRAC (obvious so far). Once done, if you want to have one separate (sub) project in Redmine for each boost library, then there is sone "manual" work to do. I m not sure about what the work would be. Best case would be to simply select all tickets that have a component of the name of a specific library and have a way in redmine to move those tickets into a specific sub project for this library. 2. Maybe I m wrong but it looks to me that the Redmine community have been divided during the last year. Some developers didnt agree with the development process and forked the project to make the Chili project ( https://www.chiliproject.org/ ) I dont know what is the impact on the tools but it might be a good idea to have some clues about the stability of the tool project. Or maybe it s not important, anyway now you know about it. Also, Redmine being faster looks true for my experience, BUT the scale of boost project and the fact that a lot of people can access it makes me think that maybe Redmine will be as slow as TRAC for this project with the same hardware ( also Ruby isnt reputed to be fast execution...) so as Dave says I guess the only way to check this is to test it. Hope it helps. Joel Lamotte
on Mon Apr 09 2012, Klaim - Joël Lamotte <mjklaim-AT-gmail.com> wrote:
On Mon, Apr 9, 2012 at 11:49, Dave Abrahams <dave@boostpro.com> wrote:
The thing that's lost by this idea is any sense of being able to achieve a substantial speedup ASAP without lots of work, experimentation, etc. There's a script to convert Trac to Redmine. If it works and Redmine is fast enough, we're done solving the speedup problem. If not, consider alternatives.
Hi,
I dont have an advice on this but I have just 3 infos about that that might be good to take into account :
1. I suspect that the conversion script will make the tickets exactly in the same configuration than in TRAC (obvious so far). Once done, if you want to have one separate (sub) project in Redmine for each boost library, then there is sone "manual" work to do. I m not sure about what the work would be. Best case would be to simply select all tickets that have a component of the name of a specific library and have a way in redmine to move those tickets into a specific sub project for this library.
Yes. That work can probably be done by a script, but it can also be a separate script. It's a separate job.
2. Maybe I m wrong but it looks to me that the Redmine community have been divided during the last year. Some developers didnt agree with the development process and forked the project to make the Chili project ( https://www.chiliproject.org/ ) I dont know what is the impact on the tools but it might be a good idea to have some clues about the stability of the tool project. Or maybe it s not important, anyway now you know about it.
Oh my! I hadn't heard about that at all. It does complicate things quite a bit. On first inspection it looks like ChiliProject has more energy than Redmine but of course it's hard to know if these things will sustain themselves. I guess under these circumstances I'd be inclined to suggest that we first try a Trac instance hosted at OSUOSL and see if that changes anything, to give us a little more time to see if ChiliProject looks like it's going to win. Getting off Trac makes sense in the long run for various reasons, but that can wait if we can get a speedup in some other way.
Also, Redmine being faster looks true for my experience, BUT the scale of boost project and the fact that a lot of people can access it makes me think that maybe Redmine will be as slow as TRAC for this project with the same hardware
We wouldn't be constrained to the same hardware; it would be hosted by OSUOSL, which has more resources.
( also Ruby isnt reputed to be fast execution...)
So I hear.
so as Dave says I guess the only way to check this is to test it.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Mon, Apr 9, 2012 at 9:46 PM, Dave Abrahams <dave@boostpro.com> wrote:
Oh my! I hadn't heard about that at all. It does complicate things quite a bit. On first inspection it looks like ChiliProject has more energy than Redmine but of course it's hard to know if these things will sustain themselves. I guess under these circumstances I'd be inclined to suggest that we first try a Trac instance hosted at OSUOSL and see if that changes anything, to give us a little more time to see if ChiliProject looks like it's going to win. Getting off Trac makes sense in the long run for various reasons, but that can wait if we can get a speedup in some other way.
Also, Redmine being faster looks true for my experience, BUT the scale of boost project and the fact that a lot of people can access it makes me think that maybe Redmine will be as slow as TRAC for this project with the same hardware
We wouldn't be constrained to the same hardware; it would be hosted by OSUOSL, which has more resources.
Who will perform the move? -- Olaf
On Thu, Apr 12, 2012 at 9:08 PM, Olaf van der Spek <ml@vdspek.org> wrote:
On Mon, Apr 9, 2012 at 9:46 PM, Dave Abrahams <dave@boostpro.com> wrote:
Oh my! I hadn't heard about that at all. It does complicate things quite a bit. On first inspection it looks like ChiliProject has more energy than Redmine but of course it's hard to know if these things will sustain themselves. I guess under these circumstances I'd be inclined to suggest that we first try a Trac instance hosted at OSUOSL and see if that changes anything, to give us a little more time to see if ChiliProject looks like it's going to win. Getting off Trac makes sense in the long run for various reasons, but that can wait if we can get a speedup in some other way.
Also, Redmine being faster looks true for my experience, BUT the scale of boost project and the fact that a lot of people can access it makes me think that maybe Redmine will be as slow as TRAC for this project with the same hardware
We wouldn't be constrained to the same hardware; it would be hosted by OSUOSL, which has more resources.
Who will perform the move?
... -- Olaf
on Thu Apr 19 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Apr 12, 2012 at 9:08 PM, Olaf van der Spek <ml@vdspek.org> wrote:
On Mon, Apr 9, 2012 at 9:46 PM, Dave Abrahams <dave@boostpro.com> wrote:
Oh my! I hadn't heard about that at all. It does complicate things quite a bit. On first inspection it looks like ChiliProject has more energy than Redmine but of course it's hard to know if these things will sustain themselves. I guess under these circumstances I'd be inclined
to suggest that we first try a Trac instance hosted at OSUOSL and see if that changes anything, to give us a little more time to see if ChiliProject looks like it's going to win. Getting off Trac makes sense in the long run for various reasons, but that can wait if we can get a speedup in some other way.
Also, Redmine being faster looks true for my experience, BUT the scale of boost project and the fact that a lot of people can access it makes me think that maybe Redmine will be as slow as TRAC for this project with the same hardware
We wouldn't be constrained to the same hardware; it would be hosted by OSUOSL, which has more resources.
Who will perform the move?
...
I don't think anyone understands the question. What do you mean by "perform the move?" -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Apr 19, 2012 at 8:36 PM, Dave Abrahams <dave@boostpro.com> wrote:
We wouldn't be constrained to the same hardware; it would be hosted by OSUOSL, which has more resources.
Who will perform the move?
...
I don't think anyone understands the question. What do you mean by "perform the move?"
I guess under these circumstances I'd be inclined to suggest that we first try a Trac instance hosted at OSUOSL and see if
Moving Trac from it's current host to OSUOSL. What's the plan? Who's going to execute it? that changes anything, to give us a little more time to see if ChiliProject looks like it's going to win. Getting off Trac makes sense in the long run for various reasons, but that can wait if we can get a speedup in some other way. -- Olaf
on Thu Apr 19 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Apr 19, 2012 at 8:36 PM, Dave Abrahams <dave@boostpro.com> wrote:
We wouldn't be constrained to the same hardware; it would be hosted by OSUOSL, which has more resources.
Who will perform the move?
...
I don't think anyone understands the question. What do you mean by "perform the move?"
Moving Trac from it's current host to OSUOSL. What's the plan? Who's going to execute it?
I don't understand; didn't you volunteer to make this happen? Presumably it would take cooperation between a Booster and sysadmins at both IUOSL and OSUOSL. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Apr 19, 2012 at 9:12 PM, Dave Abrahams <dave@boostpro.com> wrote:
I don't think anyone understands the question. What do you mean by "perform the move?"
Moving Trac from it's current host to OSUOSL. What's the plan? Who's going to execute it?
I don't understand; didn't you volunteer to make this happen? Presumably it would take cooperation between a Booster and sysadmins at both IUOSL and OSUOSL.
I did and still do. But I don't know what to do. Who (from Boost) is dealing with IUOSL and OSUOSL? Who is managing the website and existing Trac instance? -- Olaf
on Thu Apr 19 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Apr 19, 2012 at 9:12 PM, Dave Abrahams <dave@boostpro.com> wrote:
I don't think anyone understands the question. What do you mean by "perform the move?"
Moving Trac from it's current host to OSUOSL. What's the plan? Who's going to execute it?
I don't understand; didn't you volunteer to make this happen? Presumably it would take cooperation between a Booster and sysadmins at both IUOSL and OSUOSL.
I did and still do. But I don't know what to do.
I can put you in touch with the IUOSL and OSUOSL people. A big part of this job consists of "figuring out what to do," so you not knowing what to do is part of the game, so to speak.
Who (from Boost) is dealing with IUOSL and OSUOSL?
A number of us deal with IUOSL from time to time. I think the OSUOSL interaction has mostly been me and Renée.
Who is managing the website
The website, meaning http://boost.org? It probably depends what you mean by "managing..." but in any case I don't think I know who's doing it, and I'm not sure it's relevant to the bug tracker migration.
and existing Trac instance?
The moderators and maybe a few others have admin privileges on the Trac instance via its web interface. For lower-level control, you have to deal with Dong-Inn Kim, the IUOSL sysadmin. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Fri, Apr 20, 2012 at 1:30 AM, Dave Abrahams <dave@boostpro.com> wrote:
on Thu Apr 19 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Apr 19, 2012 at 9:12 PM, Dave Abrahams <dave@boostpro.com> wrote:
I don't think anyone understands the question. What do you mean by "perform the move?"
Moving Trac from it's current host to OSUOSL. What's the plan? Who's going to execute it?
I don't understand; didn't you volunteer to make this happen? Presumably it would take cooperation between a Booster and sysadmins at both IUOSL and OSUOSL.
I did and still do. But I don't know what to do.
I can put you in touch with the IUOSL and OSUOSL people. A big part of this
Please do, let's get started.
job consists of "figuring out what to do," so you not knowing what to do is part of the game, so to speak.
I understand, but I need some starting pointers.
Who (from Boost) is dealing with IUOSL and OSUOSL?
A number of us deal with IUOSL from time to time. I think the OSUOSL interaction has mostly been me and Renée.
Who is managing the website
The website, meaning http://boost.org? It probably depends what you mean by "managing..." but in any case I don't think I know who's doing it, and I'm not sure it's relevant to the bug tracker migration.
Maybe not, I don't know whether the two are integrated or entirely separate.
and existing Trac instance?
The moderators and maybe a few others have admin privileges on the Trac instance via its web interface. For lower-level control, you have to deal with Dong-Inn Kim, the IUOSL sysadmin.
OK -- Olaf
On Fri, Apr 20, 2012 at 12:52 PM, Olaf van der Spek <ml@vdspek.org> wrote:
On Fri, Apr 20, 2012 at 1:30 AM, Dave Abrahams <dave@boostpro.com> wrote:
on Thu Apr 19 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Apr 19, 2012 at 9:12 PM, Dave Abrahams <dave@boostpro.com> wrote:
I don't think anyone understands the question. What do you mean by "perform the move?"
Moving Trac from it's current host to OSUOSL. What's the plan? Who's going to execute it?
I don't understand; didn't you volunteer to make this happen? Presumably it would take cooperation between a Booster and sysadmins at both IUOSL and OSUOSL.
I did and still do. But I don't know what to do.
I can put you in touch with the IUOSL and OSUOSL people. A big part of this
Please do, let's get started.
job consists of "figuring out what to do," so you not knowing what to do is part of the game, so to speak.
I understand, but I need some starting pointers.
Who (from Boost) is dealing with IUOSL and OSUOSL?
A number of us deal with IUOSL from time to time. I think the OSUOSL interaction has mostly been me and Renée.
Who is managing the website
The website, meaning http://boost.org? It probably depends what you mean by "managing..." but in any case I don't think I know who's doing it, and I'm not sure it's relevant to the bug tracker migration.
Maybe not, I don't know whether the two are integrated or entirely separate.
and existing Trac instance?
The moderators and maybe a few others have admin privileges on the Trac instance via its web interface. For lower-level control, you have to deal with Dong-Inn Kim, the IUOSL sysadmin.
OK
Dave? -- Olaf
on Sat Apr 28 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Fri, Apr 20, 2012 at 12:52 PM, Olaf van der Spek <ml@vdspek.org> wrote:
On Fri, Apr 20, 2012 at 1:30 AM, Dave Abrahams <dave@boostpro.com> wrote:
on Thu Apr 19 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Apr 19, 2012 at 9:12 PM, Dave Abrahams <dave@boostpro.com> wrote:
> I don't think anyone understands the question. What do you mean by > "perform the move?"
Moving Trac from it's current host to OSUOSL. What's the plan? Who's going to execute it?
I don't understand; didn't you volunteer to make this happen? Presumably it would take cooperation between a Booster and sysadmins at both IUOSL and OSUOSL.
I did and still do. But I don't know what to do.
I can put you in touch with the IUOSL and OSUOSL people. A big part of this
Please do, let's get started.
job consists of "figuring out what to do," so you not knowing what to do is part of the game, so to speak.
I understand, but I need some starting pointers.
Who (from Boost) is dealing with IUOSL and OSUOSL?
A number of us deal with IUOSL from time to time. I think the OSUOSL interaction has mostly been me and Renée.
Who is managing the website
The website, meaning http://boost.org? It probably depends what you mean by "managing..." but in any case I don't think I know who's doing it, and I'm not sure it's relevant to the bug tracker migration.
Maybe not, I don't know whether the two are integrated or entirely separate.
and existing Trac instance?
The moderators and maybe a few others have admin privileges on the Trac instance via its web interface. For lower-level control, you have to deal with Dong-Inn Kim, the IUOSL sysadmin.
OK
Dave?
Hi Olaf, If you have a specific question, please ask it. I have answered all the direct questions you've asked so far, AFAIK. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Sun, Apr 29, 2012 at 4:26 AM, Dave Abrahams <dave@boostpro.com> wrote:
If you have a specific question, please ask it. I have answered all the direct questions you've asked so far, AFAIK.
I'm confused. Did you miss my in-line responses?
I can put you in touch with the IUOSL and OSUOSL people. A big part of this
Please do, let's get started. -- Olaf
on Sun Apr 29 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Sun, Apr 29, 2012 at 4:26 AM, Dave Abrahams <dave@boostpro.com> wrote:
If you have a specific question, please ask it. I have answered all the direct questions you've asked so far, AFAIK.
I'm confused. Did you miss my in-line responses?
Perhaps. Let me try again. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Fri Apr 20 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Fri, Apr 20, 2012 at 1:30 AM, Dave Abrahams <dave@boostpro.com> wrote:
on Thu Apr 19 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Apr 19, 2012 at 9:12 PM, Dave Abrahams <dave@boostpro.com> wrote:
I don't think anyone understands the question. What do you mean by
"perform the move?"
Moving Trac from it's current host to OSUOSL. What's the plan? Who's going to execute it?
I don't understand; didn't you volunteer to make this happen? Presumably it would take cooperation between a Booster and sysadmins at both IUOSL and OSUOSL.
I did and still do. But I don't know what to do.
I can put you in touch with the IUOSL and OSUOSL people. A big part of this
Please do, let's get started.
OK, will do.
The website, meaning http://boost.org? It probably depends what you mean by "managing..." but in any case I don't think I know who's doing it, and I'm not sure it's relevant to the bug tracker migration.
Maybe not, I don't know whether the two are integrated or entirely separate.
They are entirely separate AFAIK. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Steven Watanabe wrote:
AMDG
On 04/08/2012 09:55 AM, Olaf van der Spek wrote:
On Sat, Apr 7, 2012 at 3:19 PM, Dave Abrahams <dave@boostpro.com> wrote:
I'm sorry, I thought I already posted this reply but I don't see it here.
We've heard from people who say they've never seen a Trac installation with good performance. However...
IMO it will not be productive to go through an extensive analysis of the current performance, a review of other issue tracker improvement requests, or a survey of other tracker technologies. What we need is improved performance, ASAP. The only way to know how Redmine will perform in practice for Boost is to try it.
Beman,
Is this ok with the steering committee?
I can't speak for anyone else, but throwing something in and hoping it helps is most certainly not okay with me.
+1 Personally, I love the functionality of Trac. I also depend upon it for maintaining the history of all the bugs I've had to deal with. So any change is not to be taken lightly. I agree it's slow, but it's not so slow that it holds me up or creates any big problem for me. I haven't followed this discussion so I don't know anything about the way Trac is hosted, who manages it and/or what kind of action they've undertaken to address the situation. And I've never even heard of Redmine so I can't add anything constructive to the discussion. Robert Ramey
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
on Fri Mar 23 2012, Beman Dawes <bdawes-AT-acm.org> wrote:
On Thu, Mar 22, 2012 at 12:44 PM, Olaf van der Spek <ml@vdspek.org> wrote:
Hi Beman,
Trac (performance) isn't good, we'd like to replace it with Redmine. Is the steering committe ok with this?
The steering committee would need a short proposal document that lays out the motivation for a change, the pros and cons of Redmine vs Trac, and how the transition would be accomplished. Plus a few links to relevant info. That will give the SC something specific to vote on.
Personally, Redmine seems a good choice, but I've a couple of concerns:
IIUC, performance is a major motivation. A quick try with google found many assertions that Redmine was faster than Trac, but no actual performance measurements. Has performance actually been measured?
Unlikely. I'm guessing the best way to know whether the speed works for us is to attempt the migration and see how it goes.
I also came across a case where someone moved from Trac to Redmine, then moved back again a year later because they weren't familiar enough with Ruby on Rails, and that caused them admin problems. Is that also a likely problem for Boost?
No. I don't know jack about RoR and have been administering a Redmine installation for a few years with great success. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Rene Rivera wrote:
On Thu, Mar 8, 2012 at 9:44 AM, Olaf van der Spek <ml@vdspek.org> wrote:
On Thu, Mar 1, 2012 at 1:25 AM, Dave Abrahams <dave@boostpro.com> wrote:
We *were* in communication with OSUOSL about providing more powerful
Somebody?
We are, slowly, working to get the OSUOSL system set up. But we at lest have the Boost VM running in their cluster.
--
There is a large selection of hosting (cheap or free) services for bug tracking services including track. WHen I log in to trac I think I remember that typically there are only 1 or 2 other users on line at the same time. So I wouldn't expect we'd need more than the simplest solution. SourceForge also provides this service (free) on request. So there are lots of options. Robert Ramey
participants (7)
-
Beman Dawes -
Dave Abrahams -
Klaim - Joël Lamotte -
Olaf van der Spek -
Rene Rivera -
Robert Ramey -
Steven Watanabe