develooper Front page | perl.perl5.porters | Postings from February 2017

Re: [perl #130641] Bleadperl v5.25.8-36-g6cdc5cd8f3 breaksHURRICUP/DTL-Fast-1.622.tar.gz

Thread Previous | Thread Next
Sawyer X
February 1, 2017 11:26
Re: [perl #130641] Bleadperl v5.25.8-36-g6cdc5cd8f3 breaksHURRICUP/DTL-Fast-1.622.tar.gz
Message ID:

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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About