Jonas Smedegaard <d...@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 <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. 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
