[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:

> [[PGP Signed Part:No public key for 2C7C3146C1A00121 created at 2021-12-22T23:52:06+0100 using RSA]]
> Quoting Pierre-Elliott Bécue (2021-12-22 21:42:41)
>> 
>> Jonas Smedegaard <dr at jones.dk> wrote on 22/12/2021 at 21:55:13+0100:
>> 
>> > [[PGP Signed Part:No public key for 2C7C3146C1A00121 created at 2021-12-22T21:55:09+0100 using RSA]]
>> > Quoting Pierre-Elliott Bécue (2021-12-22 17:08:46)
>> >> Jonas Smedegaard <dr at jones.dk> wrote on 22/12/2021 at 
>> >> 12:37:21+0100:
>> >> > Releasing a new major release of mistune has caused several 
>> >> > packages to no longer be usable at all.
>> >> >
>> >> > I consider this a serious issue, and have raised severity 
>> >> > accordingly.
>> >> >
>> >> > At least python-m2r have no support for mistune v2 in sight (and 
>> >> > its newer fork - python-m2r2 - does not either). 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.
>> >> >
>> >> > It seems that a release of python3-django-hyperkitty requiring 
>> >> > mistune v2 has already been uploaded to unstable as well.  That 
>> >> > is very unfortunate, and will need to be rolled back as well.  
>> >> > Mailman maintainers cc'ed.
>> >> >
>> >> > Please in future make sure to check reverse dependencies *before* 
>> >> > releasing a major new upstream release to unstable, because 
>> >> > reversal is messy (complicates package versioning).
>> >> >
>> >> >
>> >> > Kind regards, and thanks for maintaining mistune,
>> >> 
>> >> The issue is that many reverse dependencies of mistune are not 
>> >> maintained.
>> >
>> > I assume (in good faith) that you did not mean to say that the 
>> > _Debian_ packages reverse depending on mistune are all unmaintained.
>> 
>> I'm not sure that there is anything to assume. I wrote "many reverse 
>> dependencies of mistune are not maintained", and making it mean "the 
>> _Debian_ packages reverse depending on mistune are all unmaintained" 
>> would require some hard work.
>> 
>> > Please note that I did not propose to wait until _upstreams_ of 
>> > reverse dependencies can use newer major version of mistune.
>> 
>> 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).
>
>
>> > 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.
>
>
>> Testing is not impacted so far.
>
> Correct.  Unstable is impacted.

Ok, so after some end of vacation + 10 days of covid @home, I'm roughly
back on track. Sorry for the added two weeks delay.

I am eager to revert mistune (and therefore django-hyperkitty) back to
previous versions, and to open bugs against reverse deps, with new
uploads in experimental for both mistune and django-hyperkitty.

I consider a delay between bug opening and making them RC on the
reverse-deps of a month, which, added to the removal delay, means around
mid-march I'll probably reupload mistune 2.0.0 and django-hyperkitty in
unstable.

Is it fine with you?

Last but not least, do you have appropriate tooling to file bugs against
mistune reverse deps a bit more efficiently than "mail by mail"?

Cheers!
-- 
PEB