On June 26, 2020 12:47:24 PM EDT, Sergei Trofimovich <sly...@gentoo.org> wrote:
>On Fri, 26 Jun 2020 11:38:58 +0200
>Michał Górny <mgo...@gentoo.org> 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 <mgo...@gentoo.org> wrote:
>> >
>> > > Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich
><sly...@gentoo.org> napisał(a):
>> > > > On Sat, 20 Jun 2020 16:29:53 +0100
>> > > > Sergei Trofimovich <sly...@gentoo.org> wrote:
>> > > >
>> > > > > On Sat, 20 Jun 2020 16:05:38 +0200
>> > > > > Michał Górny <mgo...@gentoo.org> 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 <sly...@gentoo.org>
>> > > > > > > ---
>> > > > > > > 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 <sly...@gentoo.org> (2020-06-20)
>> > > > > > > +# Deprecated. Consider poring to python 3 and drop
>support for
>> > > > python2.
>> > > > > > > +dev-lang/python:2.7
>> > > > > > > +
>> > > > > > > # Sergei Trofimovich <sly...@gentoo.org> (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 <sly...@gentoo.org> (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.
As discussed elsewhere, there are tools to show which packages only support Py2
etc.
There is no discrimination of which packages get masked and when. Additionally,
masking seems to drive the attention vice all the other discussions, bugs, etc.
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.
In the end, the mask seems to work quickest when only a couple of people can
sift through the packages in the tree. We have a deadline...
Look at the list of packages masked for removal and how many get "saved." I
think it is fairly clear how effective it is... Without wasting time opening
bugs, begging on the ML for support, explaining that there are tools to help
devs see these things etc.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
