develooper Front page | perl.perl5.porters | Postings from June 2018

[perl #132671] Bleadperl v5.27.6-206-g16ada235c3 breaksJGAMBLE/Algorithm-QuineMcCluskey-0.16.tar.gz

Thread Next
From:
slaven@rezic.de via RT
Date:
June 10, 2018 12:45
Subject:
[perl #132671] Bleadperl v5.27.6-206-g16ada235c3 breaksJGAMBLE/Algorithm-QuineMcCluskey-0.16.tar.gz
Message ID:
rt-4.0.24-6513-1528634721-752.132671-15-0@perl.org
Dana Fri, 08 Jun 2018 12:21:27 -0700, craig.a.berry@gmail.com reče:
> On Fri, Jun 8, 2018 at 1:43 AM, slaven@rezic.de via RT
> <perlbug-followup@perl.org> wrote:
> > Dana Thu, 24 May 2018 05:22:12 -0700, davem reče:
> >> On Wed, May 23, 2018 at 10:39:26PM -0700, slaven@rezic.de via RT
> >> wrote:
> >> > Dana Mon, 23 Apr 2018 05:23:45 -0700, davem reče:
> >> > > On Fri, Apr 20, 2018 at 12:00:02AM +0100, Dave Mitchell wrote:
> >> > > > (this was followed up with
> >> > > > https://rt.cpan.org/Public/Bug/Display.html?id=123989
> >> > > > )
> >> > > >
> >> > > > Since its been confirmed that its bugs in List-MoreUtils-XS,
> >> > > > I propose that this perl ticket is removed from the 5.28
> >> > > > blockers
> >> > > > list.
> >> > >
> >> > > Now done.
> >> > >
> >> >
> >> > Please can you make sure that affected CPAN modules get a ticket
> >> > in
> >> > its own queues when removing something from the blockers list? I
> >> > did
> >> > so for this one: https://rt.cpan.org/Ticket/Display.html?id=125391
> >>
> >> I fail to see how the act of determining that a particular issue is
> >> not a
> >> blocker makes me personally responsible for raising tickets against
> >> one or
> >> more CPAN modules which have a dependency on a CPAN module which has
> >> bug?
> >
> > We have a de facto process for dealing with breakages caused by
> > changes in perl. If this breakage is a documented one and unlikely to
> > be reverted, then the tickets go directly to the affected CPAN
> > modules. If it is not, then a BBC ticket is created first, with a
> > link to a blocker ticket. If now this BBC ticket is closed or the
> > blocker link removed, then the information chain about the breakage
> > is effectively broken --- without informing the CPAN authors.
> >
> > And it does not matter if a CPAN module is directly or only
> > indirectly affected. The author of the indirectly affected module may
> > decide to use an alternative module or implementation.
> >
> > So yes: anybody closing a ticket or removing a blocker link should
> > make sure that every interested party is informed.
> 
> I fail to see how removing the blocker link causes any loss of
> information as long as the ticket is left open.  Interested parties
> can act on it whenever, well, they take an interest.

In this case possibly interested parties (i.e. the author of the affected CPAN module) were not informed at all.

>  IMO the core
> grant recipients have quite enough to do keeping up with the core RT
> queue and its security-related equivalent (which has seen a major
> uptick in activity in the last couple of years).  Making them
> responsible for CPAN RT as well is more or less implementing a command
> economy ("Thou shalt increase productivity by 100%!") -- more work
> with no resources to do it.  Of course it would be great if some
> volunteer(s) stepped up to provide this service, but there is no
> reason this activity should block core releases, which is what the
> blocker link is for.

A blocker is created for a purpose: to evaluate and possibly avoid breakage which would be caused by a new perl release. If it was decided that the breakage will happen nevertheless, then I would expect that there's some help for the affected authors to fix their code. But at the very minimum it should be made sure that known breakages are at least communicated to the authors.


---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=132671

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About