[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

On Mon, 14 Oct 2019 20:18:10 +0200
Gregor Riepl <onitake@gmail.com> wrote:

> > As of now, calibre is not of sufficient quality to be part of a
> > Debian release and until it drops all Python2 requirements, it must
> > be considered RC buggy.  
> Is your quality argument based on the Calibre author's shenanigans?
> https://www.reddit.com/r/linux/comments/9wodtq/calibre_wont_migrate_to_python_3_author_says_i_am/

No. It is based just on the removal of Python2 from Debian and
avoiding special cases. Right now, any and every package in Debian
testing which requires Python2 and has no Python3 alternative in
Debian or ready for upload is of poor quality for no other reason than
that. All such packages are of such poor quality that the package should
be removed from testing - in an orderly manner, leaf packages first.
That is in the best interests of all users, despite what may or may not
happen to any particular subset(s) of users.

The decision flow is easy - if the answer in each case is "no", then
move on to the next and if you get to the bottom, the bug should be RC.

* Has the package already been removed from testing?
* Is a Python3-only version already in Debian?
* Is a Python3-only version available upstream?
* Does the package have any reverse dependencies?
* If you get here, it is already too late, there have already been
  enough warnings. Upgrade the bug to RC and get the package
  auto-removed from testing.

Step and repeat to get to the next packages in the dependency chain.

No special pleading. No whining. No excuses.

No buts and no exceptions. No "middle ground".

Get the packages which have done the work into Debian testing to get us
a clean Python3 package list ready for the next release.

Volunteer time is our most precious resource and it cannot be wasted on
packages which fail to meet release criteria. Requiring Python2 is RC
buggy - simple as that. The only manageable way to implement that is to
make all leaf packages RC, step and repeat down the chain until this
enormous task is complete.

Python2 removal is a huge task and I'm only too aware that I don't have
the free time now to do much to actually help it. This is the only way
to get the removal done and get to the next Debian release - which
after all, is the purpose of the testing suite in Debian.

I'm aware of the history of calibre but I really don't care about what
happens to calibre per se. I just care that calibre is not a special
case that ends up blocking fixes to it's dependencies. For example, if
any one of the current Python2 dependencies of calibre is able to drop
Python2 support and calibre is the only reverse dependency then
nothing about the upload removing Python2 support from the dependency
should be prevented just because it's used by calibre as opposed to any
other random Python2 leaf package. To do that, calibre should be
removed from testing as soon as it is clear that a Python3 version of
calibre is not available and BEFORE a Python3 version of any one of
it's dependencies gets delayed.

None of the arguments about users going to other sources apply. This
isn't about removing calibre from unstable - only from testing. That's
what raising the severity means - autoremoval, not RM. Even if the
package was removed from unstable, it's still in Buster and can be
installed from there. If that's not good enough then, sorry - I really
don't care.

The calibre package - as it exists currently in Debian testing - is not
of sufficient quality to remain in Debian testing and should be
removed as soon as is practical. As it is a leaf package, that should
be now, there is no benefit to Debian in any further delay.

Precisely the same applies to tftpy and vland and a range of others
which I personally care about much more than I care about calibre. Many
of those other packages have already been removed from testing and that
was the correct step to take for all the right reasons.

None of the above relates specifically to calibre either. Any other
package in the same position can be substituted without any change in
the correctness of the result.

> And in particular: https://bugs.launchpad.net/calibre/+bug/1714107
> One thing to consider here is the relatively large user base of
> Calibre that doesn't know much or care about the Python 2
> deprecation. They will simply perceive dropping Calibre as a bad move
> on Debian's side and rush towards other packages of significantly
> lower quality. PPAs, Snap and the like do more harm than keeping
> compatibility in some way for the time being.

Raising the severity of the bug doesn't change any of this.
> While I agree that Debian should not put up with stubborn developers,
> I also don't agree that end users should take the fall for Debian
> maintainer's decisions.
> Perhaps a middle ground has to be found until a viable Py3 fork of
> Calibre is available, or someone steps up and writes Py3
> compatibility patches without dropping Py2 support? This here seems
> like a good starting to achieve what Calibre's author wants:
> https://github.com/plone/Products.CMFPlone/issues/2184#issuecomment-359445243
> Though, in the long run, somebody will have to convince Kovid that
> writing Py3 code is worthwhile... Or take over maintenance.

Again, nothing to do with raising the severity of the bug to RC.

Calibre is nothing special - it's a Python2 leaf package like vland
and tftpy and any one of far too many others. It should be removed from
testing on the basis that a Python3 version is not forthcoming and
there are dependencies which will be able to drop their Python2 support
(or be removed from Debian entirely) once calibre is no longer
considered in the rm-python2 transition due it to not being present
in testing.

Calibre can stay in unstable - it will go FTBFS, of course, but that
isn't a problem either, IMHO. It's calibre's problem - not Debian's
problem. There's always the option of users installing the old Python2
stuff from Buster to keep calibre hobbling along.

Debian is the higher priority here. Calibre would be a nice to have but
it does not deserve to cause delays on anybody else's voluntary
effort. No package has that right.


Neil Williams

Attachment: pgpbgoXsqAdVp.pgp
Description: OpenPGP digital signature

Reply to: