Hi, Trac, the bugs tracker used, is really slow. Using it is a bad experience, every single time. Would it be possible to use a better bugs tracker? -- Olaf
On 12/4/2011 6:30 PM, Olaf van der Spek wrote:
Trac, the bugs tracker used, is really slow. Using it is a bad experience, every single time. Would it be possible to use a better bugs tracker?
We are aware of the issues with the Trac install. We are working to transition it, and other services, to another server. After that we will consider other transitions, like moving to other bug tracking systems. Such transitions are never easy. And are horrible painful for a project as large as Boost. So please be patient. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On Mon, Dec 05, 2011 at 01:30:13AM +0100, Olaf van der Spek wrote:
Hi,
Trac, the bugs tracker used, is really slow. Using it is a bad experience, every single time.
There's nothing particularly wrong with Trac per se as I understand it. It's more a matter of the resources available on the Boost servers vs. the very high load placed on them.
Would it be possible to use a better bugs tracker?
Changing the bug tracker would break every single link made to it in the wild, not to mention that migrating data from one tracker brand to another brand is costly and non-trivial. Any suggestion to migrate to another system (may it be build system, version control system, bug tracking system), should have some rudimentary measurements of the costs involved and the likely benefits that would come out of it. -- Lars Viklund | zao@acc.umu.se
On Mon, Dec 5, 2011 at 1:48 AM, Lars Viklund <zao@acc.umu.se> wrote:
On Mon, Dec 05, 2011 at 01:30:13AM +0100, Olaf van der Spek wrote:
Hi,
Trac, the bugs tracker used, is really slow. Using it is a bad experience, every single time.
There's nothing particularly wrong with Trac per se as I understand it.
I've never seen a fast Trac instance.
It's more a matter of the resources available on the Boost servers vs. the very high load placed on them.
What resources are available and what kind of load is there?
Would it be possible to use a better bugs tracker?
Changing the bug tracker would break every single link made to it in the wild, not to mention that migrating data from one tracker brand to another brand is costly and non-trivial.
True. One option might be to continue using the old one for existing bugs. Another option is to setup a forwarder to forward from the old to the new tracker to avoid broken links.
Any suggestion to migrate to another system (may it be build system, version control system, bug tracking system), should have some rudimentary measurements of the costs involved and the likely benefits that would come out of it.
I assume we agree on the performance problems of the current tracker, right? -- Olaf
On Mon, Dec 5, 2011 at 12:26 PM, Olaf van der Spek <ml@vdspek.org> wrote:
On Mon, Dec 5, 2011 at 1:48 AM, Lars Viklund <zao@acc.umu.se> wrote:
On Mon, Dec 05, 2011 at 01:30:13AM +0100, Olaf van der Spek wrote:
Hi,
Trac, the bugs tracker used, is really slow. Using it is a bad experience, every single time.
There's nothing particularly wrong with Trac per se as I understand it.
I've never seen a fast Trac instance.
It's more a matter of the resources available on the Boost servers vs. the very high load placed on them.
What resources are available and what kind of load is there?
Would it be possible to use a better bugs tracker?
Changing the bug tracker would break every single link made to it in the wild, not to mention that migrating data from one tracker brand to another brand is costly and non-trivial.
True. One option might be to continue using the old one for existing bugs. Another option is to setup a forwarder to forward from the old to the new tracker to avoid broken links.
Any suggestion to migrate to another system (may it be build system, version control system, bug tracking system), should have some rudimentary measurements of the costs involved and the likely benefits that would come out of it.
I assume we agree on the performance problems of the current tracker, right?
Lars? -- Olaf
On Sun, Dec 11, 2011 at 04:49:29PM +0100, Olaf van der Spek wrote:
On Mon, Dec 5, 2011 at 12:26 PM, Olaf van der Spek <ml@vdspek.org> wrote:
I assume we agree on the performance problems of the current tracker, right?
Lars?
In my eyes, the problem is not with the tracker. It's the underdimensioned set of servers we have. Rene probably has decent figures on what things are consuming the server resources, and might have a decent battle plan for migration to more servers. I don't see any point in jumping to conclusions about whether a piece of software should be replaced simply because the net load of all services is high. Everything on the svn.boost.org server is collectively slow to some degree, may it be web, trac, svn, regression tables, etc. A more productive avenue of investigation would be to find out whether services can be deployed over more machines, and whether that would improve things. -- Lars Viklund | zao@acc.umu.se
On Sun, Dec 11, 2011 at 8:59 PM, Lars Viklund <zao@acc.umu.se> wrote:
On Sun, Dec 11, 2011 at 04:49:29PM +0100, Olaf van der Spek wrote:
On Mon, Dec 5, 2011 at 12:26 PM, Olaf van der Spek <ml@vdspek.org> wrote:
I assume we agree on the performance problems of the current tracker, right?
Lars?
In my eyes, the problem is not with the tracker. It's the underdimensioned set of servers we have. Rene probably has decent figures on what things are consuming the server resources, and might have a decent battle plan for migration to more servers.
Rene?
I don't see any point in jumping to conclusions about whether a piece of software should be replaced simply because the net load of all services is high.
Sure
Everything on the svn.boost.org server is collectively slow to some degree, may it be web, trac, svn, regression tables, etc.
A more productive avenue of investigation would be to find out whether services can be deployed over more machines, and whether that would improve things.
True Who's managing those services? Rene? -- Olaf
On Thu, Dec 15, 2011 at 8:03 AM, Olaf van der Spek <ml@vdspek.org> wrote:
On Sun, Dec 11, 2011 at 8:59 PM, Lars Viklund <zao@acc.umu.se> wrote:
On Sun, Dec 11, 2011 at 04:49:29PM +0100, Olaf van der Spek wrote:
On Mon, Dec 5, 2011 at 12:26 PM, Olaf van der Spek <ml@vdspek.org> wrote:
I assume we agree on the performance problems of the current tracker,
right?
Lars?
In my eyes, the problem is not with the tracker. It's the underdimensioned set of servers we have. Rene probably has decent figures on what things are consuming the server resources, and might have a decent battle plan for migration to more servers.
Rene?
I thought I had already replied to this thread with the relevant information. But to repeat.. We've been aware of the server problems for a long time. And we are already working towards moving to more capable server(s). -- -- 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, Dec 15, 2011 at 4:20 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
In my eyes, the problem is not with the tracker. It's the underdimensioned set of servers we have. Rene probably has decent figures on what things are consuming the server resources, and might have a decent battle plan for migration to more servers.
Rene?
I thought I had already replied to this thread with the relevant information. But to repeat.. We've been aware of the server problems for a long time. And we are already working towards moving to more capable server(s).
You had. I was just wondering whether more details were available, as I haven't seen any info about it on this list. -- Olaf
On Sun, Dec 11, 2011 at 8:59 PM, Lars Viklund <zao@acc.umu.se> wrote:
In my eyes, the problem is not with the tracker. It's the underdimensioned set of servers we have. Rene probably has decent figures on what things are consuming the server resources, and might have a decent battle plan for migration to more servers.
Just wondering, are you aware of any public Trac instance that is fast? Got a link? Olaf
on Sun Dec 04 2011, Lars Viklund <zao-AT-acc.umu.se> wrote:
On Mon, Dec 05, 2011 at 01:30:13AM +0100, Olaf van der Spek wrote:
Hi,
Trac, the bugs tracker used, is really slow. Using it is a bad experience, every single time.
There's nothing particularly wrong with Trac per se as I understand it. It's more a matter of the resources available on the Boost servers vs. the very high load placed on them.
Would it be possible to use a better bugs tracker?
Changing the bug tracker would break every single link made to it in the wild, not to mention that migrating data from one tracker brand to another brand is costly and non-trivial.
Not always. There are scripts for migrating from Trac to Redmine, for example, and it's possible in principle to set up redirects for all the links. Of course, that may be, as you say, non-trivial.
Any suggestion to migrate to another system (may it be build system, version control system, bug tracking system), should have some rudimentary measurements of the costs involved and the likely benefits that would come out of it.
Certainly that is very true. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 12/15/2011 9:38 PM, Dave Abrahams wrote:
Any suggestion to migrate to another system (may it be build system, version control system, bug tracking system), should have some rudimentary measurements of the costs involved and the likely benefits that would come out of it. Certainly that is very true.
Here's one benefit: right now, Trac is giving me an internal error (database is locked) whenever I try to log in. This is not an isolated incident. I've complained about this here several times before, as have others. It's a Friday evening. How much load could there possibly be on the server? I just want to see my bug list. This is pathetic. -- Eric Niebler BoostPro Computing http://www.boostpro.com
on Sat Dec 17 2011, Eric Niebler <eric-AT-boostpro.com> wrote:
On 12/15/2011 9:38 PM, Dave Abrahams wrote:
Any suggestion to migrate to another system (may it be build system, version control system, bug tracking system), should have some rudimentary measurements of the costs involved and the likely benefits that would come out of it.
Certainly that is very true.
Here's one benefit: right now, Trac is giving me an internal error (database is locked) whenever I try to log in. This is not an isolated incident. I've complained about this here several times before, as have others. It's a Friday evening. How much load could there possibly be on the server? I just want to see my bug list. This is pathetic.
I've just poked OSUOSL about our hosting request again. If nothing else they can reconstitute the Trac there and give it sufficient resources for a while. Hopefully they'll be able to do a Redmine migration also... -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 12/17/2011 7:56 AM, Dave Abrahams wrote:
on Sat Dec 17 2011, Eric Niebler<eric-AT-boostpro.com> wrote:
On 12/15/2011 9:38 PM, Dave Abrahams wrote:
Any suggestion to migrate to another system (may it be build system, version control system, bug tracking system), should have some rudimentary measurements of the costs involved and the likely benefits that would come out of it.
Certainly that is very true.
Here's one benefit: right now, Trac is giving me an internal error (database is locked) whenever I try to log in. This is not an isolated incident. I've complained about this here several times before, as have others. It's a Friday evening. How much load could there possibly be on the server? I just want to see my bug list. This is pathetic.
I've just poked OSUOSL about our hosting request again. If nothing else they can reconstitute the Trac there and give it sufficient resources for a while. Hopefully they'll be able to do a Redmine migration also...
Having looked at Redmine this week. About the only complaint I've seen about it is that its UI is not as good as Trac. But that seems like a minor issue given it's other attributes. So I'm all for moving to Redmine ASAP. In other words.. Either we move directly to Redmine in the new server. Or see if we can move to Redmine in the current server. And the holidays might be the perfect time to do this move since it will make it less impact on users. Rene. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
on Sat Dec 17 2011, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
On 12/17/2011 7:56 AM, Dave Abrahams wrote:
on Sat Dec 17 2011, Eric Niebler<eric-AT-boostpro.com> wrote:
On 12/15/2011 9:38 PM, Dave Abrahams wrote:
Any suggestion to migrate to another system (may it be build system, version control system, bug tracking system), should have some rudimentary measurements of the costs involved and the likely benefits that would come out of it.
Certainly that is very true.
Here's one benefit: right now, Trac is giving me an internal error (database is locked) whenever I try to log in. This is not an isolated incident. I've complained about this here several times before, as have others. It's a Friday evening. How much load could there possibly be on the server? I just want to see my bug list. This is pathetic.
I've just poked OSUOSL about our hosting request again. If nothing else they can reconstitute the Trac there and give it sufficient resources for a while. Hopefully they'll be able to do a Redmine migration also...
Having looked at Redmine this week. About the only complaint I've seen about it is that its UI is not as good as Trac.
Overall, I'd say it's better. Just IMO of course.
But that seems like a minor issue given it's other attributes. So I'm all for moving to Redmine ASAP. In other words.. Either we move directly to Redmine in the new server. Or see if we can move to Redmine in the current server. And the holidays might be the perfect time to do this move since it will make it less impact on users.
I think it would be less disruptive to move Trac hosting and give the OSUOSL people some time to get the Redmine translation perfect. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (5)
-
Dave Abrahams -
Eric Niebler -
Lars Viklund -
Olaf van der Spek -
Rene Rivera