On Sat, Jun 20, 2020 at 1:36 PM Aaron Bauman <b...@gentoo.org> wrote:
> On Sat, Jun 20, 2020 at 10:32:28AM +0200, Ulrich Mueller wrote:
> > >>>>> On Sat, 20 Jun 2020, Aaron Bauman wrote:
> >
> > >> # Aaron Bauman <b...@gentoo.org> (2020-06-20)
> > >> # Py2 only
> > >> # Removal in 14 days
> >
> > I see these short deadlines quite often recently. Any reason why this
> > can't be the usual 30 days?
> >
> Hi, Ulrich. Yes, the deadlines are meant to speed up the process as we
> have *roughly* 1000+ pkgs which must be converted to py3 or removed
> before we can drop the interpreter.

Wouldn't it make more sense to just file bugs on ALL the impacted
packages, wait a few weeks, and then makes ALL of them at once, with
the regular 30d deadline?

Or if filing bugs is administratively difficult then just post a list
with packages and maintainers on -dev - this has been done for changes
in the past.

Right now it seems like some maintainers are finding out that their
packages are impacted for the first time by having their packages
masked.  That means that end-users get a package mask notice and start
taking action.  Then a few days later the package is unmasked.  Of
course, by then half the users have probably started migrating to
other packages - perhaps ones that are less suitable for them.

You seem to think that maintainers should know if they're maintaining
a v2-only package.  I suspect that most maintainers don't pay that
close attention to what versions of python are supported by their
various packages, and neither do most users.  If it runs then it runs,
and most don't care which interpreter is being used.  I get that it
impacts the python team but we need to make these issues more visible
to maintainers.

Maintainers often have an assortment of packages, and probably don't
realize when any particular one has a particular python compatibility

If it is difficult for you to identify all the impacted packages, why
would it be any easier for a maintainer who has probably spent less
time than you hunting down v2-only packages?

It seems like we really need a better solution here.  And just masking
a package without filing any bug beforehand doesn't really seem
in-line with policy.  We don't even do that for serious security


Reply via email to