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

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Why do you even bother with RT when you're just going to reject the bugs because the reporter doesn't want to subscribe to your dev mailing list?

    Why don't you just set RT to forward reports to the mailing list and save us both a lot of time?
    • Hi Chris,

      I'm sensing some frustration in your post. Let me see if I can give you some perspective from where I'm coming from.

      For the large part RT has been ignored by the Catalyst developers. The reasons are two fold:

      1) Only a select number of people have access to the RT queue.

      2) The currency for development discussion has been the mailing list(s).

      The majority of bug reports and feature requests up to this point have been handled on the catalyst and catalyst-dev mailing lists. As a Catalyst "core" members, I decided that the RT queues should get some love. You might have seen my last few posts from May where i've detailed some of the work I've done.

      Now, I don't think you're giving me a fair assessment when you say I'm "just going to reject the bugs." I've applied pending patches, written tests, and patched bugs in hopes that we could a) tidy up the RT mess and b) make Catalyst (and related projects) as stable as possible.

      In order to make some sense of the ball of yarn, I've had to assign some "personal" priority to the tickets in the queue. In general, the easier it is for me to do, the sooner the ticket got worked on. This meant that things like documentation patches were applied pretty much immediately. I also think that bug reports are more important that feature requests. Any obvious bug reports have been worked on and closed, others requiring some explanation or at least a test case have been replied to and marked as "stalled."

      At this point, all we're left with are wishlist items. mst and I looked over these items and came to the conclusion that due to our development policy, that being one of consensus from the core group, we would have to open the items up for discussion. Furthermore due to the age of some of the tickets we didn't even know how relevant they were today.

      Thus, by rejecting a ticket and notifying the author that the dev list is the most appropriate place for that type of ticket, we would hope that if the ticket was still valid and the author still had a vested interest in the feature, they would make a commitment to explain the request to the list wherein all of the core members, plus other people who have a vested interest in the project can have a crack at determining its merit.

      Having said all that, I understand your point of view. I am hesitant to auto-forward all RT tickets to the list, but I will commit myself to sending the wishlist items I've recently rejected to the dev list on the authors' behalf. Obviously this doesn't mean anyone will do anything with it, but each ticket will be open for comments by the developers and the community.

      Thank you for your continued involvement,

      -Brian
      • You're right, it wasn't fair of me to generalize so much. When I searched rt.cpan.org more carefully I saw that the number of outright rejections was smaller than I recollected.

        As maintainer (or co-maintainer) of many packages, I'm aware of how much time it takes to field bug reports and feature requests. That time is why I can't afford join the mail list of every project to which I contribute bugs (179 rt.cpan.org tickets over 6 years, with 6 rejections).

        With Perl::Critic, we usually add feature requests