unsanctioned python 2.7 crusade

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

unsanctioned python 2.7 crusade

Jason A. Donenfeld-3
Hi,

Aaron has marked tons of important and useful Python 2.7 packages for removal:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d85e166dd999c354a5346fbb57aaaa68cc6f38ac

There are quite a few useful packages in here.

Can we not do this prematurely? I've revered this commit until such a
thing an be appropriately agreed upon. Many of those packages are
actively maintained upstream packages. abcde, beets, and tahoe-lafs
immediately jump out.

Thanks,
Jason

Reply | Threaded
Open this post in threaded view
|

Re: unsanctioned python 2.7 crusade

Rich Freeman
On Thu, Dec 5, 2019 at 8:42 AM Jason A. Donenfeld <[hidden email]> wrote:
>
> Hi,
>
> Aaron has marked tons of important and useful Python 2.7 packages for removal:
>
> Can we not do this prematurely? I've revered this commit until such a
> thing an be appropriately agreed upon.

Might make sense to wait to mask them at the same time as masking
python 2.7 itself?  Maybe file a bug if not already done to make
maintainers aware that this is coming?

I assume the python team is the one deciding when python 2.7 has to go
(after all, who else is going to maintain it?).  The fact that this is
about a month off did come up in another recent thread but I don't
think it was intended as a formal announcement.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: unsanctioned python 2.7 crusade

Jason A. Donenfeld-3
On Thu, Dec 5, 2019 at 2:56 PM Rich Freeman <[hidden email]> wrote:

>
> On Thu, Dec 5, 2019 at 8:42 AM Jason A. Donenfeld <[hidden email]> wrote:
> >
> > Hi,
> >
> > Aaron has marked tons of important and useful Python 2.7 packages for removal:
> >
> > Can we not do this prematurely? I've revered this commit until such a
> > thing an be appropriately agreed upon.
>
> Might make sense to wait to mask them at the same time as masking
> python 2.7 itself?  Maybe file a bug if not already done to make
> maintainers aware that this is coming?
>
> I assume the python team is the one deciding when python 2.7 has to go
> (after all, who else is going to maintain it?).  The fact that this is
> about a month off did come up in another recent thread but I don't
> think it was intended as a formal announcement.

It's one thing to mask python libraries in general. If gentoo isn't
going to support 2.7, then those libraries don't make sense to  keep
around.

It's quite another to mask random packages that have USE flags to
optionally support whatever python 2.7 library. If you're going to
last rites these, talk with the maintainer first, and only then, send
emails one at a time. Doing that en masse isn't appropriate.

On another topic, I'd prefer for python 2.7 not to be removed from
gentoo. Tons of code still uses it.

Reply | Threaded
Open this post in threaded view
|

Re: unsanctioned python 2.7 crusade

Rich Freeman
On Thu, Dec 5, 2019 at 8:59 AM Jason A. Donenfeld <[hidden email]> wrote:
>
> It's quite another to mask random packages that have USE flags to
> optionally support whatever python 2.7 library. If you're going to
> last rites these, talk with the maintainer first, and only then, send
> emails one at a time. Doing that en masse isn't appropriate.

++ - I have no idea if that happened.  For anything USE-controlled it
would make more sense to file a bug or mask the package-flag combo
itself.

>
> On another topic, I'd prefer for python 2.7 not to be removed from
> gentoo. Tons of code still uses it.
>

I'm sure a million people would share that preference.  I'm not sure
what the upstream/security status is of 2.7.  Obviously to keep it
around it would need to be reasonably secure, and somebody within
Gentoo would have to want to maintain it.  That's basically the
criteria for keeping anything like this around.  If somebody stepped
up and said "I'm maintaining 2.7 and here is why it will remain
secure..." I doubt they'd get a lot of resistance.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: unsanctioned python 2.7 crusade

William Breathitt Gray
On Thu, Dec 05, 2019 at 09:24:26AM -0500, Rich Freeman wrote:

> On Thu, Dec 5, 2019 at 8:59 AM Jason A. Donenfeld <[hidden email]> wrote:
> >
> > It's quite another to mask random packages that have USE flags to
> > optionally support whatever python 2.7 library. If you're going to
> > last rites these, talk with the maintainer first, and only then, send
> > emails one at a time. Doing that en masse isn't appropriate.
>
> ++ - I have no idea if that happened.  For anything USE-controlled it
> would make more sense to file a bug or mask the package-flag combo
> itself.
>
> >
> > On another topic, I'd prefer for python 2.7 not to be removed from
> > gentoo. Tons of code still uses it.
> >
>
> I'm sure a million people would share that preference.  I'm not sure
> what the upstream/security status is of 2.7.  Obviously to keep it
> around it would need to be reasonably secure, and somebody within
> Gentoo would have to want to maintain it.  That's basically the
> criteria for keeping anything like this around.  If somebody stepped
> up and said "I'm maintaining 2.7 and here is why it will remain
> secure..." I doubt they'd get a lot of resistance.
>
> --
> Rich

If Python 2.7 is EOL upstream then it sounds like upstream will not be
maintaining it any longer; i.e. no more bug fixes nor support. That
means Gentoo would have to maintain its own Python 2.7 fork if it's to
remain in the repository. Naturally, maintaining a Python fork is not
something the Gentoo team is ready to do, so it makes sense to remove
Python 2.7 now that the EOL date is approaching.

Besides, the Python 2.7 EOL date has been known since 2015, so those
python 2-only packages will have had at least 5 years to migrate to
Python 3.

William Breathitt Gray

Reply | Threaded
Open this post in threaded view
|

Re: unsanctioned python 2.7 crusade

Aaron Bauman-2
In reply to this post by Jason A. Donenfeld-3
On Thu, Dec 05, 2019 at 02:42:59PM +0100, Jason A. Donenfeld wrote:

> Hi,
>
> Aaron has marked tons of important and useful Python 2.7 packages for removal:
>
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d85e166dd999c354a5346fbb57aaaa68cc6f38ac
>
> There are quite a few useful packages in here.
>
> Can we not do this prematurely? I've revered this commit until such a
> thing an be appropriately agreed upon. Many of those packages are
> actively maintained upstream packages. abcde, beets, and tahoe-lafs
> immediately jump out.
>
> Thanks,
> Jason
>
You have obviously not read the relevant commit msg, reviewed the already
existing thread on -dev, or attempted to ask (and await a response) relevant
questions.

Jumping to conclusions does not help anyone.

<@zx2c4> that was supposed to be a || ( ... )
<@zx2c4> but for whatever reason the maintainer forgot that
<@zx2c4> so im going to correct that and remove eyeD3 from the list<@zx2c4> and unmask it
<@zx2c4> b-man: sound good?
<@zx2c4> slashbeast: woah look at d85e166dd999c354a5346fbb57aaaa68cc6f38ac
<@zx2c4> it's ... a lot of packages
<@zx2c4> hey removing beets too? thats not cool
<@zx2c4> and pp?
<@zx2c4> um
<@zx2c4> actually, this is ridiculous

So, clearly, you did not read the commit msg or review the thread. Magically,
you were actually going to *fix* a package and then got overwhelmed with how
many of your favorite pkgs were on the list.

Don't be lazy. Others are working to fix them and keep them around.

--
Cheers,
Aaron

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: unsanctioned python 2.7 crusade

Aaron Bauman-2
In reply to this post by William Breathitt Gray
On Thu, Dec 05, 2019 at 09:34:16AM -0500, William Breathitt Gray wrote:

> On Thu, Dec 05, 2019 at 09:24:26AM -0500, Rich Freeman wrote:
> > On Thu, Dec 5, 2019 at 8:59 AM Jason A. Donenfeld <[hidden email]> wrote:
> > >
> > > It's quite another to mask random packages that have USE flags to
> > > optionally support whatever python 2.7 library. If you're going to
> > > last rites these, talk with the maintainer first, and only then, send
> > > emails one at a time. Doing that en masse isn't appropriate.
> >
> > ++ - I have no idea if that happened.  For anything USE-controlled it
> > would make more sense to file a bug or mask the package-flag combo
> > itself.
> >
> > >
> > > On another topic, I'd prefer for python 2.7 not to be removed from
> > > gentoo. Tons of code still uses it.
> > >
> >
> > I'm sure a million people would share that preference.  I'm not sure
> > what the upstream/security status is of 2.7.  Obviously to keep it
> > around it would need to be reasonably secure, and somebody within
> > Gentoo would have to want to maintain it.  That's basically the
> > criteria for keeping anything like this around.  If somebody stepped
> > up and said "I'm maintaining 2.7 and here is why it will remain
> > secure..." I doubt they'd get a lot of resistance.
> >
> > --
> > Rich
>
> If Python 2.7 is EOL upstream then it sounds like upstream will not be
> maintaining it any longer; i.e. no more bug fixes nor support. That
> means Gentoo would have to maintain its own Python 2.7 fork if it's to
> remain in the repository. Naturally, maintaining a Python fork is not
> something the Gentoo team is ready to do, so it makes sense to remove
> Python 2.7 now that the EOL date is approaching.
>
> Besides, the Python 2.7 EOL date has been known since 2015, so those
> python 2-only packages will have had at least 5 years to migrate to
> Python 3.
>
> William Breathitt Gray
>
Wonderful response, William.

For the others who are seeking a quick "why? how? when? what?" there are these
links:

https://pythonclock.org/

https://python3statement.org/ <--- This is a fun one. All the naysayers need to
go yell at the projects too!

--
Cheers,
Aaron

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: unsanctioned python 2.7 crusade

Andreas K. Huettel
In reply to this post by Jason A. Donenfeld-3
How about adding yourself as maintainer then? :)

Am Donnerstag, 5. Dezember 2019, 14:42:59 CET schrieb Jason A. Donenfeld:

> Hi,
>
> Aaron has marked tons of important and useful Python 2.7 packages for
> removal:
>
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d85e166dd999c354a5346fb
> b57aaaa68cc6f38ac
>
> There are quite a few useful packages in here.
>
> Can we not do this prematurely? I've revered this commit until such a
> thing an be appropriately agreed upon. Many of those packages are
> actively maintained upstream packages. abcde, beets, and tahoe-lafs
> immediately jump out.
>
> Thanks,
> Jason


--
Andreas K. Hüttel
[hidden email]
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)




Reply | Threaded
Open this post in threaded view
|

Re: unsanctioned python 2.7 crusade

David Seifert
In reply to this post by Jason A. Donenfeld-3
On Thu, 2019-12-05 at 14:59 +0100, Jason A. Donenfeld wrote:

> On Thu, Dec 5, 2019 at 2:56 PM Rich Freeman <[hidden email]> wrote:
> > On Thu, Dec 5, 2019 at 8:42 AM Jason A. Donenfeld <[hidden email]
> > > wrote:
> > > Hi,
> > >
> > > Aaron has marked tons of important and useful Python 2.7 packages
> > > for removal:
> > >
> > > Can we not do this prematurely? I've revered this commit until
> > > such a
> > > thing an be appropriately agreed upon.
> >
> > Might make sense to wait to mask them at the same time as masking
> > python 2.7 itself?  Maybe file a bug if not already done to make
> > maintainers aware that this is coming?
> >
> > I assume the python team is the one deciding when python 2.7 has to
> > go
> > (after all, who else is going to maintain it?).  The fact that this
> > is
> > about a month off did come up in another recent thread but I don't
> > think it was intended as a formal announcement.
>
> It's one thing to mask python libraries in general. If gentoo isn't
> going to support 2.7, then those libraries don't make sense to  keep
> around.
>
> It's quite another to mask random packages that have USE flags to
> optionally support whatever python 2.7 library. If you're going to
> last rites these, talk with the maintainer first, and only then, send
> emails one at a time. Doing that en masse isn't appropriate.
>
> On another topic, I'd prefer for python 2.7 not to be removed from
> gentoo. Tons of code still uses it.
>

Sorry, but I'll have to disagree with you on this.

We're removing Java too from Gentoo (more implicitly than explicitly),
because the Maven/Gradle ecosystem doesn't seem to scale. There's tons
of code that uses java and java binaries too, and yet we're removing
it. Python 2 is EOL in a few weeks. We have also removed Qt4 and lost a
number of useful applications with it. At some point, we're not going
to maintain a dead interpreter anymore.


Reply | Threaded
Open this post in threaded view
|

Re: unsanctioned python 2.7 crusade

Thomas Deutschmann
On 2019-12-05 21:31, David Seifert wrote:

>> On another topic, I'd prefer for python 2.7 not to be removed from
>> gentoo. Tons of code still uses it.
>>
> Sorry, but I'll have to disagree with you on this.
>
> We're removing Java too from Gentoo (more implicitly than explicitly),
> because the Maven/Gradle ecosystem doesn't seem to scale. There's tons
> of code that uses java and java binaries too, and yet we're removing
> it. Python 2 is EOL in a few weeks. We have also removed Qt4 and lost a
> number of useful applications with it. At some point, we're not going
> to maintain a dead interpreter anymore.
For the records: Nobody in this discussion or IRC chat said

> Keep Python 2 forever.

It's about timing. From my POV and I read

> Tons of code still uses it.
               ^^^^^

the same,  there is no need to mask any Python 2 stuff _today_.

Especially when new Python project lead sent a mail [1] to this list few
weeks ago stating that there will be a _new_ last Python 2 release in
April 2020 (120 days away!).

Now please explain to me and any Gentoo user depending on Py2-only
software why you are taking actions 120(!) days in advance.

Again, nobody wants to keep Python 2 forever but starting to kill
*working* software 120 days in *advance* deserves at least an honest
justification.


PS: And given that a release in April won't break the next day, we are
actually talking about more than 120 days in advance. Security argument
is not valid because if there will be any serious vulnerability in Py2
found after this release (which will be surprising after so many years)
you can expect backports because other distributions still have to
support Py2 two more years at minimum.


[1]
https://archives.gentoo.org/gentoo-dev/message/d00a956180ab7df980ac5642e3abc179


--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


signature.asc (631 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: unsanctioned python 2.7 crusade

David Seifert
On Thu, 2019-12-05 at 21:56 +0100, Thomas Deutschmann wrote:

> On 2019-12-05 21:31, David Seifert wrote:
> > > On another topic, I'd prefer for python 2.7 not to be removed
> > > from
> > > gentoo. Tons of code still uses it.
> > >
> > Sorry, but I'll have to disagree with you on this.
> >
> > We're removing Java too from Gentoo (more implicitly than
> > explicitly),
> > because the Maven/Gradle ecosystem doesn't seem to scale. There's
> > tons
> > of code that uses java and java binaries too, and yet we're
> > removing
> > it. Python 2 is EOL in a few weeks. We have also removed Qt4 and
> > lost a
> > number of useful applications with it. At some point, we're not
> > going
> > to maintain a dead interpreter anymore.
>
> For the records: Nobody in this discussion or IRC chat said
>
> > Keep Python 2 forever.

Again, disagree. You'll hear lots of voices that are along the lines of

  "So much enterprise code won't get ported to py3, and RedHat will be
  maintaining RHEL 7 and 8 for the next 10 years, so we'll always have
  security patches to rely on. Let's just keep Python 2 for the
  foreseeable future."

many Gentoo devs have voiced that opinion, so asserting that noone says
"Keep Python 2 forever" is false, and not by a negligible margin.

>
> It's about timing. From my POV and I read
>
> > Tons of code still uses it.
>                ^^^^^
> the same,  there is no need to mask any Python 2 stuff _today_.

When we started removing Qt4, tons of code still used it. To put things
in perspective:

grep -rl 'IUSE.*python_targets_python2_7' /usr/portage/metadata/md5-
cache/ | wc -l

gives me 7070 ebuilds currently. 7070 is easily more than one and
closer to two orders of magnitude more ebuilds using python 2 than Qt4
back in the days. Removing python2 will turn into a multi-year,
monumental effort of epic proportions, and I'm willing to bet
€1000 that we'll still be stuck with it in 3 years. It will be one of
the largest undertakings of Gentoo, probably more involved than getting
rid of EAPI=5 ebuilds. Removing maintainer-needed and other semi-dead
packages is part of a proactive strategy in continuously removing and
treecleaning stale stuff from the tree. Tons of java stuff also still
works, yet we're removing it because the ebuilds are ancient and
unmaintained.

>
> Especially when new Python project lead sent a mail [1] to this list
> few
> weeks ago stating that there will be a _new_ last Python 2 release in
> April 2020 (120 days away!).
>
> Now please explain to me and any Gentoo user depending on Py2-only
> software why you are taking actions 120(!) days in advance.
>
> Again, nobody wants to keep Python 2 forever but starting to kill
> *working* software 120 days in *advance* deserves at least an honest
> justification.

So what do you propose? Starting to remove/fix 7070 ebuilds after April
2020 then? Why start in April 2020? Let's just wait till May 2029, when
RHEL 8 goes into end of maintenance support. That's a good time point
then? It doesn't matter what time point you think is suitable, *any*
time point will be arbitrary to someone. Every change breaks somebody's
workflow.

>
> PS: And given that a release in April won't break the next day, we
> are
> actually talking about more than 120 days in advance. Security
> argument
> is not valid because if there will be any serious vulnerability in
> Py2
> found after this release (which will be surprising after so many
> years)
> you can expect backports because other distributions still have to
> support Py2 two more years at minimum.

And that's exactly the straw-man argument I've been making. You can
always come up with an excuse to delay action on python 2, because
"someone, somewhere, will maintain it". Heck, if RHEL 8 abandons python
2 in 2029, let's just swap in Tauthon then, then we can use python 2
packages till 2100!

>
>
> [1]
> https://archives.gentoo.org/gentoo-dev/message/d00a956180ab7df980ac5642e3abc179
>
>


Reply | Threaded
Open this post in threaded view
|

Re: unsanctioned python 2.7 crusade

Rich Freeman
On Thu, Dec 5, 2019 at 5:23 PM David Seifert <[hidden email]> wrote:
>
> And that's exactly the straw-man argument I've been making. You can
> always come up with an excuse to delay action on python 2, because
> "someone, somewhere, will maintain it".

Hey, if somebody actually does want to maintain it I don't see any
reason it can't stick around forever.  Of course maintain means
maintain, not just ignore bugs/etc if it causes grief for other
packages and so on, or allow security issues to fester.

So far I'm getting the impression that everybody wants somebody else
to maintain it, and that is when it becomes an issue.  "WE ought to do
this" - where "WE" usually means "not me."  There is no nebulous
"Gentoo" out there who will maintain ebuilds.  If they are to stay in
the repo then somebody has to actually tend them.

If somebody wants to keep around 2.7 for a long time IMO the most
straightforward thing to do is announce a desire to do it with a plan.
I really doubt that anybody is likely to interfere, and if they do it
can always be escalated to Council.  But, again, it has to be done
right and not cause issues for other packages (at least at the start
that shouldn't be a huge problem).

Personally I've always admired the Wikipedia policy:
https://en.wikipedia.org/wiki/WP:BOLD

If you want to see a change, go about it in a positive way.  If such a
change bothers you, assume good faith, but point out the issues.
Don't over-react in either direction.  This is how 99% of everything
positive that has ever happened in Gentoo has come about.  Most of our
improvements are the result of "unsanctioned crusades."  That doesn't
mean that you should go around breaking systems left and right, but in
this case we're just talking about a mask, or announcing an intent to
do a project.

But, such a thing will certainly involve work.  IMO it is work for
diminishing returns.  If it is an itch that bothers you, though, you
can always scratch it...

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: unsanctioned python 2.7 crusade

Kent Fredric-2
In reply to this post by Aaron Bauman-2
On Thu, 5 Dec 2019 09:40:50 -0500
Aaron Bauman <[hidden email]> wrote:

> Wonderful response, William.

Just because its EOL, doesn't mean it stops working.

It just means *support* for defects and security problems is dropped.

It doesn't prevent us from:

a) vendor patching bugs
b) vendor patching security issues

So as much as I'm fervently annoyed by needing python 2 on my system
and want to get rid of it post-haste, I too think this move is too
aggressive.

It seems more sensible to me to remove things on the basis of a
*credible problem*, not on the basis of a conjecture that one could
appear in the future.

I'm not averse to change, I just understand for change to be executed
successfully, gradual and careful adjustments have to be made.

Though I deeply suspect once package.deprecated becomes a thing we can use,
we can relegate py2-only stuff there.

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: unsanctioned python 2.7 crusade

Mart Raudsepp-2
In reply to this post by David Seifert
Ühel kenal päeval, N, 05.12.2019 kell 23:23, kirjutas David Seifert:

> When we started removing Qt4, tons of code still used it. To put
> things
> in perspective:
>
> grep -rl 'IUSE.*python_targets_python2_7' /usr/portage/metadata/md5-
> cache/ | wc -l
>
> gives me 7070 ebuilds currently. 7070 is easily more than one and
> closer to two orders of magnitude more ebuilds using python 2 than
> Qt4
> back in the days.
You are dramatizing things too much on purpose here. That gives you a
list of almost all PYTHON_COMPAT packages, the majority of which
support python3 already, and will happily continue working after the
user drops python2_7 from PYTHON_TARGETS or it gets dropped from the
_PYTHON_ALL_IMPLS list in python-utils-r1.eclass.

> Removing maintainer-needed and other semi-dead
> packages is part of a proactive strategy in continuously removing and
> treecleaning stale stuff from the tree.

That's the problem right here. The mask included packages that are not
maintainer-needed, nor maintained by python@ or other projects you or
Aaron are active members of. And it was a careless mask, masking even
some things that aren't even affected, merely had python2 mentioned in
some commented out stuff, afaiu.

I don't think there would be such a huge outcry if this was done right
- involving the actual maintainers of these packages, not just going
ahead and package.masking them from under them 150+ days ahead of time
of actual upstream python2 last release. Presumably most of these
maintainers would already know whether the package is in the progress
of being ported upstream (and just needs probably less than 120 days to
complete that work and make a release), or know that it's dead and go
away. Or they don't respond, and you can p.mask them on a maintainer
honoring timeout.

As this was done is completely unacceptable. Honor your fellow
maintainers and don't trample over them like this. We already are in a
lack of manpower, don't chase more away by trying to take the easy
route and doing stuff like this without involving them via a tracker
bug or other proper ways.
If you don't maintain a package, you get to work with the maintainer,
not do as you please without involving them at all. I am not aware of
QA having such blanket authority either for such a case.


I don't think anyone can have a valid problem with package.mask of some
of the things mentioned (sabnzbd, abcde, etc), because they were indeed
maintainer-needed or sound@ (which David is part of, and is known
crickets territory) or whatnot. It seems to have found interested
maintainers, as is normal with last-rite type of package.masks.
But by including things that are actually maintained, without any
apparent involvement of those maintainers, you allow for such outcry
even for things that shouldn't be a problem, because you display ill
intent and dishonoring towards your fellow maintainers.

Honor your fellow Gentoo maintainers. Period.


Mart

signature.asc (1000 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: unsanctioned python 2.7 crusade

David Seifert
On Fri, 2019-12-06 at 10:11 +0200, Mart Raudsepp wrote:

> Ühel kenal päeval, N, 05.12.2019 kell 23:23, kirjutas David Seifert:
> > When we started removing Qt4, tons of code still used it. To put
> > things
> > in perspective:
> >
> > grep -rl 'IUSE.*python_targets_python2_7'
> > /usr/portage/metadata/md5-
> > cache/ | wc -l
> >
> > gives me 7070 ebuilds currently. 7070 is easily more than one and
> > closer to two orders of magnitude more ebuilds using python 2 than
> > Qt4
> > back in the days.
>
> You are dramatizing things too much on purpose here. That gives you a
> list of almost all PYTHON_COMPAT packages, the majority of which
> support python3 already, and will happily continue working after the
> user drops python2_7 from PYTHON_TARGETS or it gets dropped from the
> _PYTHON_ALL_IMPLS list in python-utils-r1.eclass.

Dramatizing that a significant portion of those need to be checked? Are
you going to be doing that work? Are you going to check that the
depgraph is valid? This is unlike py3.6 -> py3.7, where you just
disable the impl in python-utils and stuff keeps working. This is going
to trigger an avalanche.

>
> > Removing maintainer-needed and other semi-dead
> > packages is part of a proactive strategy in continuously removing
> > and
> > treecleaning stale stuff from the tree.
>
> That's the problem right here. The mask included packages that are
> not
> maintainer-needed, nor maintained by python@ or other projects you or
> Aaron are active members of. And it was a careless mask, masking even
> some things that aren't even affected, merely had python2 mentioned
> in
> some commented out stuff, afaiu.
>
> I don't think there would be such a huge outcry if this was done
> right
> - involving the actual maintainers of these packages, not just going
> ahead and package.masking them from under them 150+ days ahead of
> time
> of actual upstream python2 last release. Presumably most of these
> maintainers would already know whether the package is in the progress
> of being ported upstream (and just needs probably less than 120 days
> to
> complete that work and make a release), or know that it's dead and go
> away. Or they don't respond, and you can p.mask them on a maintainer
> honoring timeout.

All the examples people name (abcde, eyeD3) are either maintained by
sound, for which I gave Aaron an explicit sign-off, or they're m-n.
This really boils down to what Rich called "somebody should maintain
it, but it's not going to be me". The best example is probably sabnzbd,
which people want, but don't want to maintain.

>
> As this was done is completely unacceptable. Honor your fellow
> maintainers and don't trample over them like this. We already are in
> a
> lack of manpower, don't chase more away by trying to take the easy
> route and doing stuff like this without involving them via a tracker
> bug or other proper ways.
> If you don't maintain a package, you get to work with the maintainer,
> not do as you please without involving them at all. I am not aware of
> QA having such blanket authority either for such a case.
>
>
> I don't think anyone can have a valid problem with package.mask of
> some
> of the things mentioned (sabnzbd, abcde, etc), because they were
> indeed
> maintainer-needed or sound@ (which David is part of, and is known
> crickets territory) or whatnot. It seems to have found interested
> maintainers, as is normal with last-rite type of package.masks.
> But by including things that are actually maintained, without any
> apparent involvement of those maintainers, you allow for such outcry
> even for things that shouldn't be a problem, because you display ill
> intent and dishonoring towards your fellow maintainers.
>
> Honor your fellow Gentoo maintainers. Period.
>
>
> Mart


Reply | Threaded
Open this post in threaded view
|

Re: unsanctioned python 2.7 crusade

Thomas Deutschmann
In reply to this post by Mart Raudsepp-2
Hi,

On 2019-12-06 09:11, Mart Raudsepp wrote:
> I don't think anyone can have a valid problem with package.mask of some
> of the things mentioned (sabnzbd, abcde, etc), because they were indeed
> maintainer-needed or sound@ (which David is part of, and is known
> crickets territory) or whatnot.

I agree with your mail in general but I don't understand this part:

Since when is it acceptable for anyone to remove packages (the
package.mask entry clearly says that this package is scheduled for
removal and suspecting that any *user* will step and contact p-m for
example is naive) without any need?

Sure, if packages don't work anymore or are blocking something, we will
start last-rite process. But for the sabnzbd example (I haven't looked
closely on any other package from that list) there isn't anything
blocking and it's a working piece of software. The only thing which
stands out is: It's a Py2-only package.

I am also curious about the maintainer-needed aspect: I understand that
Python project doesn't *want* and is also *unable* to maintain all
packages dumped to their project just because like everything in Gentoo,
the project is understaffed for the amount of work. But what's the
solution here? The message everyone saying this is acceptable sends out
can be summarized as: In future, when you see a package which you are
just using will lose its maintainer, take it before anyone decides 'I
have not *any* reason and there is no need but I'll remove it just
because I can'. Face it, no single maintainer can keep up with
maintaining 30+ packages in good quality. So there's a high chance that
package will rot the same way like they are already rotting in former
herds (projects).

Therefore I appreciate packages *without* set maintainer. Because these
packages are sending an important signal: Because they are
maintainer-needed, it's OK for anyone to touch them. Assuming we still
have the rule "If you touch it and it will break, you have to fix it"
that's at least something which *can* work because we still have no
system to declare "Yes, I am the maintainer of this package but I am
fine with you touching it".


--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


signature.asc (631 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: unsanctioned python 2.7 crusade

Rich Freeman
On Fri, Dec 6, 2019 at 8:06 AM Thomas Deutschmann <[hidden email]> wrote:
>
> Sure, if packages don't work anymore or are blocking something, we will
> start last-rite process. But for the sabnzbd example (I haven't looked
> closely on any other package from that list) there isn't anything
> blocking and it's a working piece of software. The only thing which
> stands out is: It's a Py2-only package.
>

Well, that's simple enough.  If the python maintainers intend to
remove python2 then they need to remove anything that depends on it at
the same time.  Otherwise all those packages are going to break anyway
and users just end up with a mess of error messages due to a broken
depgraph.

That said, as I've already commented I think it makes more sense to
mask the reverse dependencies at the same time as masking python2
itself.

And of course for something this big it wouldn't have hurt to announce
the plans and what was going to get masked so that mistakes could get
caught.  Even though it is just a mask it is still a bit disruptive to
have packages masked/unmasked because of incorrect identification of
reverse/optional deps.

Ultimately though it is up to the python2 maintainers to decide when
they want to remove it.  If others want to step up and replace them as
python2 maintainers and they have a reasonable plan for keeping it
working that would seem like the approach that would make the most
people happy.  We can't force people to maintain python2 if they don't
want to.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: unsanctioned python 2.7 crusade

Mike Gilbert-2
On Fri, Dec 6, 2019 at 8:52 AM Rich Freeman <[hidden email]> wrote:

>
> On Fri, Dec 6, 2019 at 8:06 AM Thomas Deutschmann <[hidden email]> wrote:
> >
> > Sure, if packages don't work anymore or are blocking something, we will
> > start last-rite process. But for the sabnzbd example (I haven't looked
> > closely on any other package from that list) there isn't anything
> > blocking and it's a working piece of software. The only thing which
> > stands out is: It's a Py2-only package.
> >
>
> Well, that's simple enough.  If the python maintainers intend to
> remove python2 then they need to remove anything that depends on it at
> the same time.  Otherwise all those packages are going to break anyway
> and users just end up with a mess of error messages due to a broken
> depgraph.
>
> That said, as I've already commented I think it makes more sense to
> mask the reverse dependencies at the same time as masking python2
> itself.

It's not quite so simple as you make it sound. There really isn't a
viable way to defer removal of python2-only packages until we remove
dev-lang/python:2.7.

An increasing number of python packages are dropping support for
python2 when upstream releases new versions. When this happens, we
really need to drop python2 support from all reverse dependencies as
well. Alternative strategies like slotting or compatibility packages
are a stopgap at best, and become a problem as soon as bugs are
reported or security issues pop up.

Ripping out python2 support for all reverse dependencies of a core
package is rather daunting, and is likely to cause much more of an
uproar than the recent mask. Aaron is really tackling the low-hanging
fruit at this point: leaves on the depgraph.

Reply | Threaded
Open this post in threaded view
|

Re: unsanctioned python 2.7 crusade

Thomas Deutschmann
On 2019-12-06 16:48, Mike Gilbert wrote:

> It's not quite so simple as you make it sound. There really isn't a
> viable way to defer removal of python2-only packages until we remove
> dev-lang/python:2.7.
>
> An increasing number of python packages are dropping support for
> python2 when upstream releases new versions. When this happens, we
> really need to drop python2 support from all reverse dependencies as
> well. Alternative strategies like slotting or compatibility packages
> are a stopgap at best, and become a problem as soon as bugs are
> reported or security issues pop up.
>
> Ripping out python2 support for all reverse dependencies of a core
> package is rather daunting, and is likely to cause much more of an
> uproar than the recent mask. Aaron is really tackling the low-hanging
> fruit at this point: leaves on the depgraph.
But what's the problem here? Why do you need to rip out Py2 support? PHP
project is facing a similar situation with PHP 5.6, 7.0 and now 7.1
becoming EOL. Sure, there are way more Python packages but could you
explain why you can't do the same like we did? I.e. new versions of PHP
PECL extension also dropped support for PHP versions which are EOL. When
we bump these packages we just drop PHP versions which are no longer
able to run these extensions. But we keep at least last version still
supporting PHP version which is/become EOL until we finally get rid of
this PHP version as a whole. For example, a lot of packages are now
masked *with* dev-lang/php:5.6 because Gentoo will finally get rid of
PHP 5.6 which is EOL since 2018-12-31. But we didn't break PHP 5.6 users
by starting to remove PECL extension for this version while
dev-lang/php:5.6 was still a thing...


--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


signature.asc (631 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: unsanctioned python 2.7 crusade

Mart Raudsepp-2
In reply to this post by Thomas Deutschmann
Ühel kenal päeval, R, 06.12.2019 kell 14:06, kirjutas Thomas
Deutschmann:
> Since when is it acceptable for anyone to remove packages (the
> package.mask entry clearly says that this package is scheduled for
> removal and suspecting that any *user* will step and contact p-m for
> example is naive) without any need?

I assume the p.mask entry text wasn't optimal then.
For this specific case, sabnzbd had been in maintainer-needed for 3
months already. Unfortunately no "package up for grabs" had been sent
for this one when it was dropped to that (previous maintainer dropped
maintenance himself).

I don't see anything wrong with the idea of p.masking it in case it
could be causing problems for others (such as py2). Of course the
p.mask entry could apparently have been better, it's sad that no
"package up for grabs" happened back then months ago, and it's not nice
it was all in a big lump of maintainer-needed packages, python@
packages and packages maintained by completely unaware maintainers with
no notification period.


Mart

signature.asc (1000 bytes) Download Attachment
123