Re: [gentoo-dev] [PATCH] Split python implementations definition to separate eclass

[Patrick McLean]

On Fri, 27 Mar 2020 06:53:13 +0100
Michał Górny <mgorny@g.o> wrote:

> On Thu, 2020-03-26 at 14:03 -0700, Patrick McLean wrote:
> > This patch splits the definition of _PYTHON_ALL_IMPLS and
> > _python_impl_supported to a separate eclass, this allows overlays
> > to easily support a different set of python implementations than
> > ::gentoo without having to fork the entire suite of eclasses.
>
> NAK.  This increases the maintenance effort (even if it means having to
> open yet another file) for *zero* gain to Gentoo users.  Your policy is
> entirely broken by design and I'm against supporting it officially.
>
> The existing number of eclasses is already causing confusion and added
> maintenance effort, and it has strong justification in *a lot of shared
> code*.
>
> To say it bluntly: if you want to do stupid things, do them yourselves
> and don't expect others to help.  You get paid for that.  We just waste
> our time.
>
It can hard to keep the size of network we have in sync with upstream,
and we have quite a large number of internal repositories. The
approaches we are using are trying to strike a balance between
backwards compatibility and moving forward.

We get paid to do our job, which sometimes coincides with doing
upstream Gentoo work, and often doesn't. We have a policy to work
upstream wherever possible, this often makes certain types of tasks
take significantly more effort than if we just decided to fork
everything and work an internal overlay. These small changes are an
attempt to reduce the extra work that working upstream can create (we
generally work to support the general use case of all Gentoo users, not
just our limited use cases).

Would Gentoo as a whole be better served if we just forked everything
and stopped trying to contribute as much as possible upstream? Are some
small changes to some shared code to help us worth the amount of
contributions that we push back upstream.