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

[Jonas Smedegaard]

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.

Please note that I did not propose to wait until _upstreams_ of reverse 
dependencies can use newer major version of mistune.

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.


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

There are alternatives to abruptly abandoning support for existing 
functionaling packages already in Debian testing.


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


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


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-mailman-hackers/attachments/20211222/8d98af07/attachment.sig>