Re: [gentoo-dev] Re: [gentoo-dev-announce] */*: Mask Py2 only packages

[Rich Freeman]

On Sat, Jun 20, 2020 at 4:36 AM Sergei Trofimovich <slyfox@g.o> wrote:
>
> On Sat, 20 Jun 2020 00:43:03 -0400
> Aaron Bauman <bman@g.o> wrote:
>
> > # Aaron Bauman <bman@g.o> (2020-06-20)
> > # Py2 only
> > # Removal in 14 days
> ...
> > app-misc/golly
>
> If you decided to delete a maintained package you should file a bug against
> the maintainer. Otherwise they won't see the effect until mask hits the users.

So, I get that the python mess has been a ton of work for those
involved, and mostly thankless work.  You get complaints from people
who are interested in a particular package, but not with maintaining
the vast number of packages in an old python implementation that
probably isn't as interesting to people interested in python for the
sake of python.  As such I don't really question the removal of v2
from the tree.  I also don't question the phased approach of
progressively fixing, removing packages, etc.  This sort of thing
should be done at the convenience of the python team, who do a ton of
work behind the scenes that keeps the whole distro working.

I would suggest that process-wise there are some things that could be
done to make this sort of thing smoother in the future (and please
understand that this is intended as a lessons-learned and not so much
as criticism):

1.  Just follow the standard policies like ulm suggested and pick 30
days.  You're already doing something that is going to get complaints.
Waiting two weeks at this point won't make much difference.  Of course
exceptions can be made for pressing security issues/etc, and if these
exist just mention them up-front to deflect criticism.

2.  Help maintainers help you.  Ideally that means opening a ton of
bugs on day 1 of this whole mess against all the impacted packages.  I
get that this isn't easy.  An alternative might be to post lists of
impacted packages on -dev periodically, and when you do this stick the
maintainers on the list.  A lot of maintainers maintain a lot of
packages, and they probably won't notice if a package they maintain is
on the list, but if you stick their name on the list they can just
grep it.  I bet a lot of maintainers would pitch in if they just
realized they needed to.  I've seen lots of bugs that say "fix this,
oh and fix anything else you might happen to have with the same
problem."  The problem with this is that the people cleaning up python
probably have scripts to go detecting impacted packages, but everybody
else in the distro doesn't, and it doesn't make sense to have 100 devs
all trying to figure out if they have a package with a particular
issue, especially if the package has a quiet upstream that doesn't do
a lot of bumps.

I get that this won't fix the entire problem.  You'll get that
stubborn dev that just refuses to fix a bug.  When that happens don't
waste your time fighting WW3 - just point out that packages depending
on v2 will get masked on $DATE and move on, and ideally get the
Council to bless your decision.  If the Council doesn't bless the
decision or a compromise you can live with then just remove v2 from
the python project and make it maintainer-needed, and thus somebody
else's problem.  Don't put the weight of the world on your shoulders -
when it comes to actual work focus on the stuff that is directly
python and make the rest of us do the rest, but you need to spend a
bit of time around engagement.  A bit of up-front bug-filing or list
posts might save you a ton of harassing later.

The rest of us do need to appreciate that this is fairly thankless
work.  Maybe python v2 COULD be supported longer. But are YOU stepping
up to do that?  The existing members of the python team aren't
obligated to keep v2 in the tree.  Indeed, they aren't obligated to
maintain python at all.  Of course if some are willing to do the work
to keep v2 around then we should find a way to allow them to do so,
but I don't really see that happening.

Now I'm sure I didn't appreciate some things that happened behind the
scenes.  Accept what makes sense and reject that which does not.  And
by all means feel free to share lessons-learned that others might
benefit from.  I don't want to turn this into a criticism thread/etc,
so I'd encourage others to refrain from doing so...

-- 
Rich