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

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

Thread Previous | Thread Next
Craig A. Berry
June 8, 2018 19:21
Re: [perl #132671] Bleadperl v5.27.6-206-g16ada235c3 breaksJGAMBLE/Algorithm-QuineMcCluskey-0.16.tar.gz
Message ID:
On Fri, Jun 8, 2018 at 1:43 AM, via RT
<> wrote:
> Dana Thu, 24 May 2018 05:22:12 -0700, davem reče:
>> On Wed, May 23, 2018 at 10:39:26PM -0700, 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
>> > > >
>> > > > )
>> > > >
>> > > > 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:
>> 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.  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.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About