[Pkg-mailman-hackers] [Pkg-matrix-maintainers] Bug#1002380: drops attributes used by reverse dependencies

[Pierre-Elliott Bécue]

Jonas Smedegaard <dr at jones.dk> wrote on 22/12/2021 at 23:52:11+0100:
>> Well, I was under the impression that
>> 
>> >>> Concretely I propose to revert this by a (messy) 2.0.0+really0.8.4 
>> >>> release until reverse dependencies can use the newer major version 
>> >>> of mistune.
>> 
>> meant indeed to wait until the reverse dependencies were sorted out 
>> which generally requires to wait until upstream fixes the issue 
>> (except if one likes big quilt patches and maintaining the software's 
>> code on their own).
>
> That is precisely what I did *not* imply (so it seems it was good that I 
> mentioned my non-assumption since apparently you _did_ assume stuff).  
>
> Let me try avoid false assumptions by expanding:
>
> I propose to revert this by a (messy) 2.0.0+really0.8.4 release until 
> reverse dependencies somehow (with or without upstream cooperation) can 
> use the newer major version of mistune (or, if taking unreasonably long, 
> kick any reverse dependencies from testing).

I clearly inferred the impact of what "until reverse dependencies can
use the newed major version of mistune" implied. I think it was
reasonable to do so instead of wondering where your cursor was on that
matter.

But I'm happy to see that you are more relaxed on what you expect!

>> > My proposal is to *collaborate* with your peers in Debian now - not 
>> > continue(!) to make choices without coordination with those packages 
>> > directly affected by those choices.
>> 
>> Maybe you wanted to suggest that I should *collaborate* more, but you 
>> did not write that and, as I tend to try not to assume what one says, 
>> writes or means, I did not read that.
>
> Sorry!
>
> I did indeed mean to encourage more collaboration, and apologize if that 
> failed to get across.
>
>
>> >> If I follow your opinion on this, the following issues arise:
>> >> 
>> >>  1. There is no proper way for software to be mistune 0.8.4 and 
>> >>     mistune 2.0.0 compatible at the same way, so the reverse 
>> >>     dependencies won't be able to update without mistune 2.0.0 
>> >>     being in unstable
>> >
>> > Not sure what you imply by "proper".
>> 
>> appropriate, suitable, relevant, reasonable, …
>> 
>> > There are alternatives to abruptly abandoning support for existing 
>> > functionaling packages already in Debian testing.
>> 
>> Note that since the upload, autopkgtests for the involved 
>> reverse-dependencies were failing and therefore mistune was not 
>> planned to migrate from unstable to testing. There was therefore no 
>> chance mistune would break these packages in testing, and I was not 
>> pressing anyone to sort that out.
>>
>> Now that a serious bug against mistune is opened, even if these 
>> autopkgtests get sorted out because these very reverse-dependencies 
>> are updated, mistune will not migrate anyway (which will prevent to 
>> break other reverse-dependencies).
>
> Yes, I am aware, and that is what I describe as "abruptly": Now that 
> mistune v1 is gone, there is no way to work on any package depending on 
> that except for switching to v2.
>
> ...which is the reason I propose to revert for now.

And I did not say that I refuse this idea. In my first mail I said that
I would like to hear your opinion on how to solve the matter of
unmaintained reverse dependencies, and also that I'd like it to stay as
it is for now.

What I failed to write is that "for now" is not "for three months", but
I fixed that in my second reply to you.

>> Testing is not impacted so far.
>
> Correct.  Unstable is impacted.

-- 
PEB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 853 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-mailman-hackers/attachments/20211222/ef5b8d10/attachment-0001.sig>