Front page | perl.perl5.porters |
Postings from February 2017
On 01/27/2017 04:46 PM, Dave Mitchell wrote: > On Fri, Jan 27, 2017 at 08:29:39AM +0100, Andreas Koenig wrote: >> After a BBC, we must face it, there is a need to improve either perl or >> CPAN. If it is CPAN, module authors need help, and there's no way to >> declare that as somebody else's problem. > I suppose the main thing here is who is "responsible" for opening > RT/github tickets for those distributions? The diagnoses found here can > then be easily relayed to the authors. In the past such tickets normally > seem to magically appear - but I don't know whether anyone here considers > it one of their normal roles (in the same way that I don't personally > worry about whether the latest versions of CPAN modules have been brought > into blead; people like Chris Williams seem to just magically do it.) I definitely agree Chris Williams is magical. :) As for the BBC workflow: I believe Andreas phrased it well: If there's a BBC, either perl is broken and needs fixing or a module is broken and needs fixing. The latter includes tests that are written incorrectly, as it seems this case might be. I don't know if we ever clarified a strict BBC handling policy, but the following seems to me what is happening: * A smoker opens a BBC ticket. * In the ticket we determine if perl is doing the right thing or not. * If we're doing the right thing, we (usually Andreas, Slaven, Jim - for which I'm very grateful) open a ticket with the module. Sometimes this is accompanied with a patch. * We make a decision on whether we should revert or not, depending on the amount of breakage and the importance of the change we've made. This seems to me like a very good workflow, as it really tries to balance requirements and to serve the community well. We know of the affect our changes have on modules and module authors know if they made any mistakes. As to Dave's question: Whose responsibility is it to open the RT/Github ticket for the distribution? I think we should be responsible of it. This serves the purpose of both alerting the author, but also alerting the users of the offending distribution, and finally allows us to easily track and prove the interaction with the author to try and accommodate this situation. Yves once made a point I keep thinking about: Issue trackers are not just for the author. They are primarily for the user, so they have a place to both interact and report issues, but also a resource for coordinating on fixes. It makes me think of how often I find in RT queues a patch that wasn't applied yet, or an explanation of what I did wrong. This is what I mean by helping the users of the distribution. The other reasons (helping the author and us) I think are pretty clear. I am willing to usurp the role of making sure all BBCs have a correlating ticket in the RT or Github issues queue of the associated distribution, if this is something we see falling through the cracks.Thread Previous | Thread Next