NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

use Perl

All the Perl that's Practical to Extract and Report

A grant for rt.cpan.org hardware? More | Login | Reply

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Without JavaScript enabled, you might want to use the classic discussion system instead. If you login, you can remember this preference.

yes (Score:1)

by rjbs (4671)

I would *also* like the ability to pick a different bug tracking system to display information on search.cpan, but rt.cpan.org is intolerably slow. Faster would be much, much better -- and possibly a second grant for other improvements.

--
rjbs
- Re: (Score:2)
  
  by petdance (2468)
  
  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.
  
  --
  --
  xoa
  - Re:yes (Score:1)
    
    by rjbs (4671) on 2007.10.31 11:52 (#58699) Homepage Journal
    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.
    
    --
    rjbs
    Reply to This
    
    Parent
    - Re: RT slow (Score:1)
      
      by markjugg (792)
      
      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: (Score:2)
      
      by jesse (2531)
      
      Want a commit bit?
      - Re: (Score:1)
        
        by Alias (5735)
        
        Dear god please yes.
    - Project-specific bugtrackers (Score:1)
      
      by hex (3272)
      
      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 [usefulinc.com] has a specific property for bugtracker URL; see the discussion on miyagawa's journal [perl.org].
      - Re: (Score:1)
        
        by rjbs (4671)
        
        META.yml *has* a place for this:
        
        http://module-build.sourceforge.net/META-spec-current.html#resources [sourceforge.net]
        
        It's just that search.cpan.org doesn't do anything about it.
        
        --
        rjbs
        
        Re: (Score:1)
        
        by hex (3272)
        
        Oh, right. Well, people here know how I feel about search.cpan.org.