Catalyst 5.7014 is out the door. Hopefully that will stop the flood of questions about a "strange uri_for() behavior." With that done, I've taken out 5 more RT tickets.
Two extremely old wishlist items were rejected (RT #26758, RT #24132). This is basically due to the fact that they were over a year old, and really should be talked about on the dev list if they are still inclined to have them resolved.
A couple others required that I cook up a test or two to ensure the patch was applying was satisfactory (naturally, we would always hope to have a test submitted along side the patch): RT #26455, RT #34437.
The last ticket seems to have been related to a regression in 5.7013, as the ticket author claims the latest release fixed the issue. Closed! (RT #35994)
Re:RT vs. maillist
tsee on 2008-05-28T08:09:09
If it's an @perl.org mailing list, then don't even think of having RT mail forwarded to that. It isn't accepted by the perl.org MTA. I found that out first-hand.Re:RT vs. maillist
LTjake on 2008-05-28T13:10:55
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,
-BrianRe:RT vs. maillist
ChrisDolan on 2008-05-29T01:31:47
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 to the svn-hosted TODO.pod list (unless there is an easy solution with existing code) rather than rejecting the request. Of course, we're a smaller community so it is feasible for all of the core developers to receive all of RT requests. But besides that, many of the requests that warrant further discussion are forwarded to the dev list. It's an easy solution that gives the requester the option of further participation (by joining the list) or walking away.
