On Wed, Nov 24, 2021 at 04:18:23PM -0500, Nicholas D Steeves wrote: > > Package: ftp.debian.org > > Severity: normal > > X-Debbugs-Cc: nstee...@gmail.com > > > > This package wasn't updated for the Python 3.9 transition and removed from > > testing on 2021-03-07. The FTBFS with 3.9 bug isn't fixed upstream and > > there are upstream maintenance problems documented at > > https://github.com/jorgenschaefer/elpy/issues/1884 > > > > Thank you for reminding me about this upstream thread. Yes, it's > definitely time that I post another follow-up message there. > > Could we please defer this removal until at least 2022-03-07 as a > reasonable compromise? I think it's uncharitable and ablist to put more > pressure than that on a project whose maintainer is suffering from hand > injury/tendonitis...these things take a long time to resolve--years, not > months--and if we're a project that truly believes in diversity, > empathy, and equal opportunity, then we must accommodate people who are > struggling. Hi Nicholas. This is now up to ftp-masters but I'll state my opinion on this. Out of 8 or so RM requests for Python FTBFS stuff not in testing that I filed yesterday this one was the hardest, but I decided to send it both because a maintainer can object to it and because removing a package even from sid is not the end of life for the package. As I see this, if a package doesn't work it should be removed (I don't know whether this package works with 3.9 and especially 3.10 or only the tests fail), if a package works but FTBFS it should definitely stay out of testing and may be removed from unstable if it hinders some progress like some transitions (I think this isn't the case here). There may be also other cases when a package should be removed even if it works, but it always can be reuploaded later when the problems are fixed. This shouldn't be viewed as a threat to the upstream, it's not "find a maintainer or we will remove the package", it's "the package is RC-buggy by our standards and also FTBFS, and so far nobody fixed that and if the upstream has no maintainer then it's unlikely it will be fixed upstream soon". So on one hand I'm fine with keeping this package in sid if it provides some value to its users and will keep doing that when Python 3.10 is the default in sid, though the FTP/Release/Security teams may have another view on this as it FTBFS, and on the other hand I don't see a huge problem with removing it, especially if it doesn't work, as it can always be reinstated.
> I'm also not sure what would be a sensitive way to broach a deadline > upstream. As mentioned above, I don't think this is necessary. What is necessary is fixing the RC bugs which can be done by the community. -- WBR, wRAR
signature.asc
Description: PGP signature
