I have no idea why rt.cpan.org remains such an utterly slow-almost-to-the-point-of-no-longer-being-useful website, but something really needs to be done about it.
I can't help but wonder if the Perl Grants Committee would buy Jesse a dedicated machine to run it on (I hear it's tacked onto the side of a server with a number of other things, but I could be wrong).
Do people think this would be a worth use of the community's money?
I certainly like the idea. Many people have been frustrated by the slowness of CPAN's RT. I don't know if the grant committee will approve it since we don't have a proposal, but it's worth a shot.
Re:Yes!
brian_d_foy on 2007-10-31T19:02:51
For such a small organization with so little work to do, it seems that waiting for a proposal is just needless process. You can make any rules that you like, and you can awards grants how you like. Be proactive rather than reactive.
Really, shouldn't TPF be out there looking for things to improve rather than waiting for someone to make a grant proposal (which apparently are often summarily rejected just on format)? If you really want to be helping the community, you make it as easy as possible for the community you are serving.
At least, that's how I ran Perl Mongers and how I run The Perl Review and Stonehenge's Rock Star Grants.Re:Yes!
Ovid on 2007-11-01T11:43:11
For such a small organization with so little work to do...Allison does very little handling our legal issues. The new artistic license just wrote itself. Jim Brandt finds running the conference committee a breeze. Ask and Robert are just laughing out how little work it takes to maintain all of our servers. Andy just waves his hand and press releases get written for him. I found running the grant committee so relaxing and stress free that I finally stepped down. Kirsten just looks at our Web sites and the pages write and redesign themselves. I'm sure Kurt has written a spreadsheet that simply handles all of the treasurer tasks for him. His printer magically spits out the checks for him to sign, no thought involved.
And there's more. So much more. We're doing better at communicating this (we've gotten tons of positive feedback on our blog), but this is still one of our biggest stumbling blocks. Since Andy handles PR for Perl, care to volunteer to join us and write up everything we do (that can be publicly discussed, that is)?
:) Oh, and we still need a corporate liaison. You could volunteer for that. I was suggested for it, but I need a break. Oh, and I've ideas on software we need written to make some of our processes smoother
... Re:Yes!
brian_d_foy on 2007-11-01T14:47:09
Ah, bullshit Ovid. Whine whine whine. TPF isn't an organization with volunteers all doing part-time stuff. It isn't a big foundation with millions of dollars in a full time staff responding to thousands of grant applications. You talk about a lot of things that happened in the past by people who don't need to be parts of the grant process. Why are you using that as an excuse about why the grant process can't be different?
I could volunteer for all sorts of things, but why should I? I don't need TPF to accomplish my goals. I already publish The Perl Review, give out grants through Stonehenge, helop with PAUSE, use.perl, the perlfaq, and many other things. I've already put my literal money where my mouth is.
Let's also remember that I ran Perl Mongers with roughly the same mission. I know what I'm talking about because I've been there and done that. I never whined about how much work is was though.
Re:Yes!
brian_d_foy on 2007-11-01T14:53:39
That is, TPF is an organization with volunteers all doing part-time stuffRe:Yes!
Ovid on 2007-11-01T15:00:36
I don't whine about how much work it is unless someone tells me that it's not. And I don't understand why you're getting hostile. I apologize if my tone was offensive. I meant it to be tongue-in-cheek, but clearly it didn't come across that way.
Re:yes
petdance on 2007-10-31T16:06:26
FWIW, I've been in the process of moving my queues for {Test::,}WWW::Mechanize over to Google Code because of the slow. Also, because I like Google Code's bug tracking facilities more than RT.Re:yes
rjbs on 2007-10-31T16:52:25
Yeah, I saw your recent post to module-authors (?). I don't mind RT per se, but rt.cpan.org's slowness, plus some other issues*, make it a big pain.
* Some examples
- can't easily get a listing of all bugs for all my queues
- can't shut off wildly-spammy email interface
- logins are way, way too short-lived (compounds slowness)
- public/private URL for bug makes redirection after login hateful
I'd love to see these fixed. I once offered to sponsor having them fixed, but the answer I got was something like, "No one should have to pay for this, we'd like to make it better for free."
We're clearly getting *much* more than we're paying for, so I'm not grouchy about that. I'd just love to be able to pay for improvements, too.
In the meantime, yeah, being bound to RT by default is problematic.Re: RT slow
markjugg on 2007-10-31T17:45:02
I agree with all your points.
The public/private URL thing drives me bonkers.
At work we use RT on nearly-dedicated hardware with plenty memory, and it is still very slow. I did DB-level debugging, and that didn't seem to be the issue. Something in the Perl code seemed to be very slow, but I have yet to pin down what that is.
This is with RT 3.6.1.
Re:yes
jesse on 2007-10-31T19:11:15
Want a commit bit?Re:yes
Alias on 2007-10-31T23:33:44
Dear god please yes.Project-specific bugtrackers
hex on 2007-11-08T12:55:14
being bound to RT by default is problematic.Yeah. There are a number of distributions that maintain their own bugtrackers (which may well be integrated with source control, like Trac is). It would be advantageous to be able to specify the bugtracker location in META.yml or some other form of structured data. In fact, DOAP has a specific property for bugtracker URL; see the discussion on miyagawa's journal.
Re:Project-specific bugtrackers
rjbs on 2007-11-08T13:38:00
META.yml *has* a place for this:
http://module-build.sourceforge.net/META-spec-current.html#resources
It's just that search.cpan.org doesn't do anything about it.Re:Project-specific bugtrackers
hex on 2007-11-08T14:52:16
Oh, right. Well, people here know how I feel about search.cpan.org.
Re:Let's take a small step back here.
Phred on 2007-10-31T16:53:02
Here's what I am seeing right now. Loading page http://rt.cpan.org/Public/ took 3.584 seconds according to FasterFox, but the in page time reads 'Time to display: 0.181015'. My ping time to rt.cpan.org is about 90 ms.
My search for bugs on Apache::Dispatch http://rt.cpan.org/Public/Dist/Display.html?Name=Apache%3A%3ADispatch took 7.67 seconds according to fasterfox, and page time reads 'Time to display: 5.985952'. My search for bugs on mechanize http://rt.cpan.org/Public/Dist/Display.html?Name=WWW%3A%3AMechanize took 14.397 seconds on fasterfox, with 'Time to display: 16.456881'. Loading http://rt.cpan.org/Public/Bug/Display.html?id=18921 took 4.649 fasterfox seconds, and 'Time to display: 2.294158'
I can keep going here but it is obvious to me that there are some performance concerns.
Re:Let's take a small step back here.
Alias on 2007-10-31T23:36:31
One example for me...
Resolving a bug, with comment.
Time to load, around 20+ seconds.
Time page says it took, 3.5 seconds.Re:Let's take a small step back here.
jesse on 2007-10-31T23:45:44
Adam,
You're a developer. You _know_ how to report bugs. (You also have tools like YSlow and Firebug which can give you real numbers)
But
1) what IP are you coming from
2) What URL were you starting from.
3) What URL did you end up at?
4) how long did one of the aforementioned tools tell you it took?
5) What _exact_ time did it happen at?
What you gave me is basically no better than "it's slow. and lied to me." - Which isn't much to work with.Re:Let's take a small step back here.
Alias on 2007-11-01T00:00:46
I was in a hurry:)
Point me at the RT queue for rt.cpan.org and I'll file it properly.Re:Let's take a small step back here.
jesse on 2007-11-01T00:13:56
The cpan-questions address on the front page of the site will log it in the right place.
I have a minion with a whole slew of tasks related to fixing up the source for publication and fixing a couple of the worst _known_ performance issues over the next couple weeks. When we do that, we'll be able to cpan rt.cpan and move bug tracking to rt.cpan.;) Re:Let's take a small step back here.
Alias on 2007-11-01T02:40:00
I've been sending stuff to that address, and apart from a short period after the most recent upgrade, they fall into the bit bucket and I never know what state they are in after an initial "thanks for the message" response.
Is the queue actually visible somewhere?
Re:Let's take a small step back here.
cbrandtbuffalo on 2007-11-01T11:19:17
FYI, I'm following along and if it turns out that hardware is part of the problem, TPF will do what we can to fix things. As it is, it appears Jesse is on the case and has a few things to try before we buy new hardware.
