Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7

[Sergei Trofimovich]

On Fri, 26 Jun 2020 13:41:13 -0400
Aaron Bauman <bman@g.o> wrote:

> On June 26, 2020 12:47:24 PM EDT, Sergei Trofimovich <slyfox@g.o> wrote:
> >On Fri, 26 Jun 2020 11:38:58 +0200
> >Michał Górny <mgorny@g.o> wrote:
> >
> >> On Fri, 2020-06-26 at 09:51 +0100, Sergei Trofimovich wrote:
> >> > On Fri, 26 Jun 2020 07:29:45 +0000
> >> > Michał Górny <mgorny@g.o> wrote:
> >> >
> >> > > Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich
> ><slyfox@g.o> napisał(a):
> >> > > > On Sat, 20 Jun 2020 16:29:53 +0100
> >> > > > Sergei Trofimovich <slyfox@g.o> wrote:
> >> > > >
> >> > > > > On Sat, 20 Jun 2020 16:05:38 +0200
> >> > > > > Michał Górny <mgorny@g.o> wrote:
> >> > > > >
> >> > > > > > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich
> >wrote:
> >> > > > > > > Give maintainers the chance to act and flag packages that
> >pull in
> >> > > > python:2.7.
> >> > > > > > > Signed-off-by: Sergei Trofimovich <slyfox@g.o>
> >> > > > > > > ---
> >> > > > > > >  profiles/package.deprecated | 4 ++++
> >> > > > > > >  1 file changed, 4 insertions(+)
> >> > > > > > >
> >> > > > > > > diff --git a/profiles/package.deprecated
> >> > > > b/profiles/package.deprecated
> >> > > > > > > index a756e845f47..bb661571962 100644
> >> > > > > > > --- a/profiles/package.deprecated
> >> > > > > > > +++ b/profiles/package.deprecated
> >> > > > > > > @@ -17,6 +17,10 @@
> >> > > > > > >
> >> > > > > > >  #--- END OF EXAMPLES ---
> >> > > > > > >
> >> > > > > > > +# Sergei Trofimovich <slyfox@g.o> (2020-06-20)
> >> > > > > > > +# Deprecated. Consider poring to python 3 and drop
> >support for
> >> > > > python2.
> >> > > > > > > +dev-lang/python:2.7
> >> > > > > > > +
> >> > > > > > >  # Sergei Trofimovich <slyfox@g.o> (2020-02-22)
> >> > > > > > >  # virtual/libstdc++ has only one sys-libs/libstdc++-v3
> >provider.
> >> > > > > > >  # Use that instead. Or even better use none of them.
> >It's a
> >> > > > > >
> >> > > > >
> >> > > > > > It will trigger the same for packages that support *only*
> >> > > > > > Python 2.7, as well as these that support 2.7 in addition
> >to 3
> >> > > > because
> >> > > > > > they have 2.7 deps.
> >> > > > >
> >> > > > > If we expect actions by developers on both cases I don't see
> >a
> >> > > > problem with that.
> >> > > >
> >> > > > Pushed as:
> >> > > >
> >https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049
> >> > > > with full text being:
> >> > > >
> >> > > > +# Sergei Trofimovich <slyfox@g.o> (2020-06-26)
> >> > > > +# Deprecated.
> >> > > > +# - optional python:2.7 dependency should be dropped if no
> >reverse
> >> > > > +#   dependencies are using it.
> >> > > > +# - mandatory python:2.7 depepndency will require package
> >porting
> >> > > > +#   or package removal if no reverse dependencies are using
> >it.
> >> > > > +dev-lang/python:2.7
> >> > >
> >> > > You've just introduced 829 CI warnings
> >> >
> >> > That's the intention.
> >> >
> >> > > effectively disabling the ability to distinguish *new* problems
> >in these packages.
> >> >
> >> > Correct. Citing above:
> >> >
> >> > "If we expect actions by developers on both cases I don't see a
> >problem with that."
> >> >
> >> > I assume we still do.
> >>
> >> Not exactly.  You've pinpointed the wrong target.
> >>
> >> First of all, we want people to support Python 3.  Removing support
> >for
> >> Python 2 is a secondary goal.
> >
> >What is the desired end state here? All packages that depend on
> >python should support python3?
> >
> >> Flagging packages that support Python 2 in addition to Python 3
> >> and cause no trouble in py2 cleanup is doubtful.
> >
> >What is "py2 cleanup"? I still struggle to understand what packages
> >require change and which do not. Is there one pager doc that explains
> >a few things for me:
> >- How packages are picked for masking? Maybe we can deprecate them
> >instead? Or we (I) can write a bit of code that flags packages
> >requiring
> >  maintainers' attention.
> >- What is the expected end state for the "py2 cleanup"?
> >
> >The doc would also be a good link to add to recently added "# Py2 only"
> >masks as well.
> >
> >> Flagging packages that support 2+3 because of their revdeps is not
> >> helpful at all.  It's just noise to the maintainer who can't remove
> >py2
> >> because of revdeps.
> >
> >I agree it can be spammy if we expect to have many packages with
> >python2 support for an extended period of time (3+ months). If it's
> >seen by others as too noisy I can revert the commit now.
> >
> >> Flagging dev-python/pypy* which needs py2 but is entirely outside
> >> the eclass system is not helpful at all.
> >
> >To pick a concrete example: from what I read above I don't see why
> >app-misc/golly was masked for removal.
>
> It was masked because it only supports Py2. The maintainer (you) decided to drop Python script support. Problem solved. Easy day. All done.

A few points:

1. "only supports Py2" does not seem to warrant to mask leaf packages
   and contradicts to Michał's explanation of cleanup effort:
     See https://archives.gentoo.org/gentoo-dev/message/04d419ebef01e80a43fc3b301e11afb6
   Please reconcile the goals within the python@ team. Ask team lead
   if not sure and provide clear guidance for others. "only supports Py2"
   is not good enough explanation.

   Leaf packages should be able to stay up to 2021-01-01, no? I'd suggest
   adding them to packages.deprecated instead.

2. I decided to drop python support in a hurry to unbreak world upgrade
   for users and myself. If I had some time I would prefer to do that in
   higher confidence and have a chance to look at python3 support in the
   package.
   But now I chucked python2 scripting entirely probably breaking a few
   users. I don't see it as a good thing.

   After Michał's explanation I am considering to restore python2 support
   while I investigate python3 support feasibility.

Thus no. Not "All done". We will probably have exactly the same conversation
next month if nothing changes in the process.

> There is no discrimination of which packages get masked and when.

I fail to interpret this phrase. Does it mean you are about to mask all
python2-only packages ~now-ish?

> Additionally, masking seems to drive the attention vice all the other discussions, bugs, etc.

I am not a native English speaker. I don't know what exactly this phrase
means.

It's not hard to get an attention by filing a bug against maintainer.
I personally read my bugs and try to act on them. I believe devs are still
required to have Bugzilla account.

I find posted links and related issues useful to assess what I should do
next and how much time I have. The blocker bug with a detailed
explanation of the effort, deadlines, next batch of packages and
whatever other stuff would be perfect there.

> As we can see, folks will complain no matter what method is used. I could spend my days opening bugs and hoping for a response, yelling loudly on the ML for others to "pitch in" etc.

I totally understand where the frustration comes from. If you
decided to do everything an your own it's challenging.

Moreover, I'm actively willing to fix whatever problems packages
I maintain have. I just need to know about them. Preferably slightly
before the change impacts users.

gentoo-dev@ emails don't work for me most of the time. At leat
I don't remember any emails in form close to
  "Port you python:2.7 packages Right Now: here is the list".

My complain is simple: I want an email directed to my email alias.
I periodically scrub bugs assigned to me and my aliases. I see that
explicit action is required from me and so on.

Is opening 100 bugs a slow procedure for you? Is it a technical
limitation or something else and you think it's useless? How about
asking others how they would like it to be handled when they complain?
What is their preference? I would be surprised to hear that
their first choice is when users complain about masked packages.

Mechanically you can auto-generate links with a one-liner script
and literally file bugs with one click. I can help with that.

I'm sure you spent more time reading only my emails in these threads
than filing bugs would take.

> In the end, the mask seems to work quickest when only a couple of people can sift through the packages in the tree.

I hope you don't optimize just for speed. Looks more like avoidance
contacting maintainers in any direct form.

Can you at least CC maintainers when masking is done?

> Without wasting time opening bugs

If I would get such a bug I would appreciate it.
Full list is also a clear indicator of how many things are yet to be done. 

> begging on the ML for support

Support for what you are doing? I'm sure if devs agree
on the ultimate goals you want to achieve you will get all the support.

Just make sure to link to the plan every time you do the change.

> explaining that there are tools to help devs see these things etc.

Probably just linking people to the dashboard and scripts would be faster.
Per-maintainer breakdown of package list would help a lot.

-- 

  Sergei