[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 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).

> 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.

>> 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).

>>  2. I'll need mailman3 to be able to enter testing at some point and I 
>>     don't think we can expect it to wait for software that is no 
>>     longer maintained upstream
>
> At some point, yes. I see no reason to rush that to the point of not
> coordinating with involved packages.

>> Apart from these two points, there are multiple cases where software 
>> are updated despite the impact on the reverse dependencies. Typically 
>> Python updates don't wait for dependencies to be ready in case of 
>> breaking changes, and that looks to me quite normal, despite it 
>> bringing more work to me as a mailman or python packages maintainer.
>
> I guess coordination within the Python team may be more relaxed.
>
> Is your point that coordination among package maintainers more generally 
> - not within the Python team - is not important?

I don't know how you fetch your assumptions on what I think or mean.

While coordination is certainly a good thing in itself, I consider it
less essential in the months that follow a stable release, because
everything is moving fast due to the delay the freeze
induced. Coordinating in this context tends to be counter productive,
and I generally accept that the packages I depend on can break mine and
so on.

>> I'd be happy to hear about how you suggest me to handle the 
>> unmaintained reverse-dependencies like m2r.
>
> Step one: File bugreports of severity important against all reverse 
> dependencies (possibly except packages maintained within the Python 
> team, not sure about those).
>
> Step two: After some time, raise severity of those bugreports.

How will it prevent mistune update in unstable to break these?

>> For now I'd rather let a serious bug block the migration of mistune 
>> from unstable to testing and accept that some packages are not working 
>> in unstable for now.
>
> It is a fact that a serious bug (this one) blocks the migration of 
> mistune and that reverse dependencies fial to work in unstable.
>
> Are you saying that you intend to not actively do anything about that - 
> just let it be and let time pass until the mess gets resolved by release 
> team or others?

I still don't understand how you manage to interpret/assume what I think
or mean.

Testing is not impacted so far.

As unstable's name mean, it's unstable and things may break. I don't
intend to ignore the problem, but I'd rather finish the discussion first
and not throw my holidays apart because you seem unhappy about what I
did and how I did it.

Anyway, it definitely can wait for a few days.

Regards,
-- 
Pierre-Elliott
-------------- 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/c0675c9b/attachment.sig>