Quoting Pierre-Elliott Bécue (2021-12-22 21:42:41) > > Jonas Smedegaard <d...@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 <d...@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. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
