[gentoo-project] For next council meeting: moving Portage to python3.6+

[gentoo-project] For next council meeting: moving Portage to python3.6+

[Daniel Robbins]

[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]

Hi there,

Zac Medico and I would like to discuss the following at the next council
meeting: moving Portage to support only python3.6+. One of the primary
benefits of this change is that it will allow us to use python's native
async implementation as we look to make Portage faster at a critical time
when we are looking to improve Portage performance. As we approach the
stabilization of python3.6 in Gentoo, it seems like a good time to discuss
the process of jettisoning 2.7 support and standardizing on 3.6 for Portage.

Right now, a custom 'asyncio-like' set of classes is used for async in
Portage. This limits interoperability with other async-friendly python
modules and produces additional maintenance overhead for the project.

Maybe even more importantly, 3.6+ compatibility also gives us the ability
to use many other new language features and reduce the maintenance overhead
of having 2.7 compatibility for the extensive Portage code-base. We expect
that this will improve the velocity of Portage development, provide
opportunities to improve Portage functionality and also allow us clean up a
lot of unnecessarily complex code (and eliminate code) that is there only
to ensure compatibility with 2.7.

Best,

Daniel

[-- Attachment #2: Type: text/html, Size: 1793 bytes --]

[gentoo-project] Re: For next council meeting: moving Portage to python3.6+

[Benda Xu]

Hi Daniel,

Daniel Robbins <drobbins@funtoo.org> writes:

> Zac Medico and I would like to discuss the following at the next
> council meeting: moving Portage to support only python3.6+. One of the
> primary benefits of this change is that it will allow us to use
> python's native async implementation as we look to make Portage faster
> at a critical time when we are looking to improve Portage
> performance. As we approach the stabilization of python3.6 in Gentoo,
> it seems like a good time to discuss the process of jettisoning 2.7
> support and standardizing on 3.6 for Portage.
>
> Right now, a custom 'asyncio-like' set of classes is used for async in
> Portage. This limits interoperability with other async-friendly python
> modules and produces additional maintenance overhead for the project.
>
> Maybe even more importantly, 3.6+ compatibility also gives us the
> ability to use many other new language features and reduce the
> maintenance overhead of having 2.7 compatibility for the extensive
> Portage code-base. We expect that this will improve the velocity of
> Portage development, provide opportunities to improve Portage
> functionality and also allow us clean up a lot of unnecessarily
> complex code (and eliminate code) that is there only to ensure
> compatibility with 2.7.

Thanks, I think drop 2.7 is that way to move forward.  

A sidenode: At present python-3.x cannot be compiled on linux-2.6.8
(RHEL/Centos 4) or linux-2.6.16 (RHEL/Centos 5) with Gentoo Prefix,
unless glibc is patched.  I am writing up a patch for review to
reintroduce glibc-2.16 and fix glibc-2.19, for them to support
python-3.x builds.

Yours,
Benda

Re: [gentoo-project] For next council meeting: moving Portage to python3.6+

[Michał Górny]

W dniu pią, 23.02.2018 o godzinie 19∶58 -0700, użytkownik Daniel Robbins
napisał:
> Hi there,
> 
> Zac Medico and I would like to discuss the following at the next council
> meeting: moving Portage to support only python3.6+. One of the primary
> benefits of this change is that it will allow us to use python's native
> async implementation as we look to make Portage faster at a critical time
> when we are looking to improve Portage performance. As we approach the
> stabilization of python3.6 in Gentoo, it seems like a good time to discuss
> the process of jettisoning 2.7 support and standardizing on 3.6 for Portage.
> 
> Right now, a custom 'asyncio-like' set of classes is used for async in
> Portage. This limits interoperability with other async-friendly python
> modules and produces additional maintenance overhead for the project.
> 
> Maybe even more importantly, 3.6+ compatibility also gives us the ability
> to use many other new language features and reduce the maintenance overhead
> of having 2.7 compatibility for the extensive Portage code-base. We expect
> that this will improve the velocity of Portage development, provide
> opportunities to improve Portage functionality and also allow us clean up a
> lot of unnecessarily complex code (and eliminate code) that is there only
> to ensure compatibility with 2.7.
> 

This is Portage's team decision. The Council has already voted on for
how long upgrade path needs to provided (that was 2 years, I think)
and what Portage developers decide beyond that is up to them.

I personally don't have anything against removing support for Python 2
(though I think many users would do). However, I wouldn't go up to 3.6+
at once, especially if 3.5 is the current version we are using. Even if
we switch the default, I think it'd be reasonable to provide a lengthy
grace period not to make upgrading Portage PITA.

This is especially important now that a new EAPI is approaching,
and we will have to deal with EAPI upgrade path.

-- 
Best regards,
Michał Górny

Re: [gentoo-project] For next council meeting: moving Portage to python3.6+

[R0b0t1]

On Sat, Feb 24, 2018 at 2:57 AM, Michał Górny <mgorny@gentoo.org> wrote:
> W dniu pią, 23.02.2018 o godzinie 19∶58 -0700, użytkownik Daniel Robbins
> napisał:
>> Hi there,
>>
>> Zac Medico and I would like to discuss the following at the next council
>> meeting: moving Portage to support only python3.6+. One of the primary
>> benefits of this change is that it will allow us to use python's native
>> async implementation as we look to make Portage faster at a critical time
>> when we are looking to improve Portage performance. As we approach the
>> stabilization of python3.6 in Gentoo, it seems like a good time to discuss
>> the process of jettisoning 2.7 support and standardizing on 3.6 for Portage.
>>
>> Right now, a custom 'asyncio-like' set of classes is used for async in
>> Portage. This limits interoperability with other async-friendly python
>> modules and produces additional maintenance overhead for the project.
>>
>> Maybe even more importantly, 3.6+ compatibility also gives us the ability
>> to use many other new language features and reduce the maintenance overhead
>> of having 2.7 compatibility for the extensive Portage code-base. We expect
>> that this will improve the velocity of Portage development, provide
>> opportunities to improve Portage functionality and also allow us clean up a
>> lot of unnecessarily complex code (and eliminate code) that is there only
>> to ensure compatibility with 2.7.
>>
>
> This is Portage's team decision. The Council has already voted on for
> how long upgrade path needs to provided (that was 2 years, I think)
> and what Portage developers decide beyond that is up to them.
>
> I personally don't have anything against removing support for Python 2
> (though I think many users would do). However, I wouldn't go up to 3.6+
> at once, especially if 3.5 is the current version we are using. Even if
> we switch the default, I think it'd be reasonable to provide a lengthy
> grace period not to make upgrading Portage PITA.
>

I am a stain upon this mailing list and my opinion is of no
consequence, but I think moving directly to 3.6 would be the best
option. Python 3.5 is a very strange situation and has some half
finished features despite being a full release. It is very likely the
release of 3.6 was rushed to fix some of what was "wrong" in 3.5
(mainly missing async features, but there are many).[1] These new
features are useful enough that they will likely outweigh any
additional work involved in adopting 3.6.

Python 2.7 will still be necessary for some hardened utilities, from memory.

Cheers,
     R0b0t1


[1]: https://docs.python.org/3/whatsnew/3.6.html

Re: [gentoo-project] For next council meeting: moving Portage to python3.6+

[Daniel Robbins]

[-- Attachment #1: Type: text/plain, Size: 2011 bytes --]

On Sat, Feb 24, 2018 at 10:55 AM, R0b0t1 <r030t1@gmail.com> wrote:
>
>
> I am a stain upon this mailing list and my opinion is of no
> consequence, but I think moving directly to 3.6 would be the best
> option. Python 3.5 is a very strange situation and has some half
> finished features despite being a full release. It is very likely the
> release of 3.6 was rushed to fix some of what was "wrong" in 3.5
> (mainly missing async features, but there are many).[1] These new
> features are useful enough that they will likely outweigh any
> additional work involved in adopting 3.6.
>

I agree. I feel like 3.5 is half-finished when it comes to its async
implementation, and 3.6+ should be the goal.

Let me put it this way to everyone -- I think we should standardize on
3.6+. It would be good if we could have consensus on that. I am pretty
confident that this is the 'right answer'.

As to *when* we do this, that I do not have the answer to. That is why I
raised it for consideration by others.

However, I see lots of benefits of making this switch sooner rather than
later. Consider that 2.7 stops being supported upstream in 2 years.

I look at it this way -- the effort we spend maintaining and working within
the code base that offers 2.7 support over the next 2 years could be used
*instead* to remove lots of cruft from the code base and standardize on
something we know we are going to need to standardize on *anyway*. That
puts us 2 years ahead of where we would be if we delay the decision.

People are willing to do the work. Mgorny expressed concern on IRC that
this would impact EAPI 7 efforts. I don't think that is the case. If
anything, it puts us in a better position.

In fact, if assurance is needed that EAPI 7 is not impacted, or that we
would work extra hard on EAPI 7 to in turn gain support for dropping lower
versions of python, I would see that as a possibility -- i.e. "we agree to
move to 3.6+ with the understanding that it should not impact EAPI 7
development."

Best,

Daniel

[-- Attachment #2: Type: text/html, Size: 2646 bytes --]

Re: [gentoo-project] For next council meeting: moving Portage to python3.6+

[M. J. Everitt]

[-- Attachment #1.1.1: Type: text/plain, Size: 2508 bytes --]

On 24/02/18 19:45, Daniel Robbins wrote:
> On Sat, Feb 24, 2018 at 10:55 AM, R0b0t1 <r030t1@gmail.com
> <mailto:r030t1@gmail.com>> wrote:
>
>
>     I am a stain upon this mailing list and my opinion is of no
>     consequence, but I think moving directly to 3.6 would be the best
>     option. Python 3.5 is a very strange situation and has some half
>     finished features despite being a full release. It is very likely the
>     release of 3.6 was rushed to fix some of what was "wrong" in 3.5
>     (mainly missing async features, but there are many).[1] These new
>     features are useful enough that they will likely outweigh any
>     additional work involved in adopting 3.6.
>
>
> I agree. I feel like 3.5 is half-finished when it comes to its async
> implementation, and 3.6+ should be the goal. 
>
> Let me put it this way to everyone -- I think we should standardize on
> 3.6+. It would be good if we could have consensus on that. I am pretty
> confident that this is the 'right answer'.
>
> As to *when* we do this, that I do not have the answer to. That is why
> I raised it for consideration by others. 
>
> However, I see lots of benefits of making this switch sooner rather
> than later. Consider that 2.7 stops being supported upstream in 2 years. 
>
> I look at it this way -- the effort we spend maintaining and working
> within the code base that offers 2.7 support over the next 2 years
> could be used *instead* to remove lots of cruft from the code base and
> standardize on something we know we are going to need to standardize
> on *anyway*. That puts us 2 years ahead of where we would be if we
> delay the decision.
>
> People are willing to do the work. Mgorny expressed concern on IRC
> that this would impact EAPI 7 efforts. I don't think that is the case.
> If anything, it puts us in a better position. 
>
> In fact, if assurance is needed that EAPI 7 is not impacted, or that
> we would work extra hard on EAPI 7 to in turn gain support for
> dropping lower versions of python, I would see that as a possibility
> -- i.e. "we agree to move to 3.6+ with the understanding that it
> should not impact EAPI 7 development."
>
> Best,
>
> Daniel
>
>  
>
So, all that remains is who's gonna do the work - both on the
stabilisation of python3.6 as a dev-lang package, and all the associated
(thousands?) of dev-python packages?
You may have brought Zac on board on the portage side of things, but
what about the rest?

[-- Attachment #1.1.2: Type: text/html, Size: 4488 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-project] For next council meeting: moving Portage to python3.6+

[Daniel Robbins]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

On Sat, Feb 24, 2018 at 12:50 PM, M. J. Everitt <m.j.everitt@iee.org>
wrote:
>
> So, all that remains is who's gonna do the work - both on the
> stabilisation of python3.6 as a dev-lang package, and all the associated
> (thousands?) of dev-python packages?
> You may have brought Zac on board on the portage side of things, but what
> about the rest?
>

Good question, here is the answer.

Standardizing on 3.6+ support for Portage does not require Gentoo to get
rid of 2.7.

The thousands? of ebuilds that need 2.7 continue to need 2.7.

Dropping support for 2.7 also doesn't require ANY code changes to Portage.
It is a strategic decision to not *continue* to maintain 2./7 support in
the future if *it becomes an annoyance or limitation* for us to do so. In
some areas, we are finding that it is.

Also, on a side-note, I have been personally helping Gentoo with the effort
of removing pycrypto dependencies from Python modules.

-Daniel

[-- Attachment #2: Type: text/html, Size: 1541 bytes --]

Re: [gentoo-project] For next council meeting: moving Portage to python3.6+

[M. J. Everitt]

[-- Attachment #1.1.1: Type: text/plain, Size: 1260 bytes --]

On 24/02/18 19:57, Daniel Robbins wrote:
> On Sat, Feb 24, 2018 at 12:50 PM, M. J. Everitt <m.j.everitt@iee.org
> <mailto:m.j.everitt@iee.org>> wrote: 
>
>     So, all that remains is who's gonna do the work - both on the
>     stabilisation of python3.6 as a dev-lang package, and all the
>     associated (thousands?) of dev-python packages?
>     You may have brought Zac on board on the portage side of things,
>     but what about the rest?
>
>
> Good question, here is the answer.
>
> Standardizing on 3.6+ support for Portage does not require Gentoo to
> get rid of 2.7.
>
> The thousands? of ebuilds that need 2.7 continue to need 2.7.
>
> Dropping support for 2.7 also doesn't require ANY code changes to
> Portage. It is a strategic decision to not *continue* to maintain 2./7
> support in the future if *it becomes an annoyance or limitation* for
> us to do so. In some areas, we are finding that it is.
>
> Also, on a side-note, I have been personally helping Gentoo with the
> effort of removing pycrypto dependencies from Python modules.
>
> -Daniel
>
>
It would seem I've overlooked the fact that python3.6 is actually pretty
well supported in Gentoo .. my apologies to the Python team for failing
to spot this.

[-- Attachment #1.1.2: Type: text/html, Size: 2880 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-project] For next council meeting: moving Portage to python3.6+

[R0b0t1]

On Sat, Feb 24, 2018 at 1:45 PM, Daniel Robbins <drobbins@funtoo.org> wrote:
> People are willing to do the work. Mgorny expressed concern on IRC that this
> would impact EAPI 7 efforts. I don't think that is the case. If anything, it
> puts us in a better position.
>
> In fact, if assurance is needed that EAPI 7 is not impacted, or that we
> would work extra hard on EAPI 7 to in turn gain support for dropping lower
> versions of python, I would see that as a possibility -- i.e. "we agree to
> move to 3.6+ with the understanding that it should not impact EAPI 7
> development."
>

Was it possible to highlight any specific issues? Changes in 3.6 are
additive; there was nothing that broke compatibility.

Cheers,
     R0b0t1

Re: [gentoo-project] For next council meeting: moving Portage to python3.6+

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 2042 bytes --]

On 02/23/2018 06:58 PM, Daniel Robbins wrote:
> Hi there,
> 
> Zac Medico and I would like to discuss the following at the next council
> meeting: moving Portage to support only python3.6+. One of the primary
> benefits of this change is that it will allow us to use python's native
> async implementation as we look to make Portage faster at a critical
> time when we are looking to improve Portage performance. As we approach
> the stabilization of python3.6 in Gentoo, it seems like a good time to
> discuss the process of jettisoning 2.7 support and standardizing on 3.6
> for Portage.
> 
> Right now, a custom 'asyncio-like' set of classes is used for async in
> Portage. This limits interoperability with other async-friendly python
> modules and produces additional maintenance overhead for the project. 
> 
> Maybe even more importantly, 3.6+ compatibility also gives us the
> ability to use many other new language features and reduce the
> maintenance overhead of having 2.7 compatibility for the extensive
> Portage code-base. We expect that this will improve the velocity of
> Portage development, provide opportunities to improve Portage
> functionality and also allow us clean up a lot of unnecessarily complex
> code (and eliminate code) that is there only to ensure compatibility
> with 2.7.
> 
> Best,
> 
> Daniel

In portage-2.3.30, portage's python API includes an asyncio event loop
policy that is compatible with PEP 492 coroutines using async and await
syntax [1]. This is possible while still maintaining backward
compatibility with python2.7, though obviously you need to use a newer
python if you want to use async and await syntax.

I've posted a code example that is compatible with python2.7 and uses
portage's event loop policy to do the same thing as emerge --regen,
complete with --jobs and --load-average options [2].

[1] https://www.python.org/dev/peps/pep-0492/
[2]
https://blogs.gentoo.org/zmedico/2018/04/17/portage-api-asyncio-event-loop/
-- 
Thanks,
Zac


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] For next council meeting: moving Portage to python3.6+

[Michał Górny]

W dniu śro, 18.04.2018 o godzinie 08∶58 -0700, użytkownik Zac Medico
napisał:
> On 02/23/2018 06:58 PM, Daniel Robbins wrote:
> > Hi there,
> > 
> > Zac Medico and I would like to discuss the following at the next council
> > meeting: moving Portage to support only python3.6+. One of the primary
> > benefits of this change is that it will allow us to use python's native
> > async implementation as we look to make Portage faster at a critical
> > time when we are looking to improve Portage performance. As we approach
> > the stabilization of python3.6 in Gentoo, it seems like a good time to
> > discuss the process of jettisoning 2.7 support and standardizing on 3.6
> > for Portage.
> > 
> > Right now, a custom 'asyncio-like' set of classes is used for async in
> > Portage. This limits interoperability with other async-friendly python
> > modules and produces additional maintenance overhead for the project. 
> > 
> > Maybe even more importantly, 3.6+ compatibility also gives us the
> > ability to use many other new language features and reduce the
> > maintenance overhead of having 2.7 compatibility for the extensive
> > Portage code-base. We expect that this will improve the velocity of
> > Portage development, provide opportunities to improve Portage
> > functionality and also allow us clean up a lot of unnecessarily complex
> > code (and eliminate code) that is there only to ensure compatibility
> > with 2.7.
> > 
> > Best,
> > 
> > Daniel
> 
> In portage-2.3.30, portage's python API includes an asyncio event loop
> policy that is compatible with PEP 492 coroutines using async and await
> syntax [1]. This is possible while still maintaining backward
> compatibility with python2.7, though obviously you need to use a newer
> python if you want to use async and await syntax.
> 
> I've posted a code example that is compatible with python2.7 and uses
> portage's event loop policy to do the same thing as emerge --regen,
> complete with --jobs and --load-average options [2].
> 
> [1] https://www.python.org/dev/peps/pep-0492/
> [2]
> https://blogs.gentoo.org/zmedico/2018/04/17/portage-api-asyncio-event-loop/

<Council hat>
For the record, I still believe this is within Portage team's domain
to decide.  Worst case, someone forks Portage and we switch to the fork
to provide better user experience.

If we really are supposed to vote on this, I would suggest a non-binding 
wording alike:

  Keeping Python<3.6 supported by Portage is recommended.

i.e. where 'abstain' votes would not result in implicit 'no' to your
request.
</Council hat>


As a developer, I am opposed to this.  I am yet to see any evidence
of claimed performance improvements, improved interoperability (with
what?) and the reduced maintenance overhead.  So far, the effort built
around asyncio seems to do the exact opposite of that, with
the refactoring adding a lot of extra code and a number of new bugs.

So please understand that I have serious doubts whether removing support
for older versions of Python would suddenly significantly reduce
the code size or complexity below the state before the refactoring
started.  This really feels like 'switching to the new cool API' more
than actually working for any real gain.

Removing support for Python 2.7 is going to be a major drawback for our
users.  I am not even going to consider those who intentionally reduce
their systems to 2.7 only for one reason or another.  However, 2.7 has
been the Gentoo's 'LTS' so far -- different versions of Python 3 come
and go but 2.7 was there for a very long time to ease the transition. 
Only recently one of the developers had to solve hard upgrade conflicts
and the simplest way of doing that was to unmerge Python 3 and use
Python 2.7 to install a new version.

Going up to 3.6 is even worse than that.  I would like to remind you
that 3.5 is the *current stable* (i.e. the target set by make.defaults).
 3.6 has stable keywords only as an effort to make it possible to test
and stabilize 3.6 support in packages sooner -- it does not imply that
we are ready to switch.  Not to mention the whole backwards
compatibility deal.

With EAPI 7 approaching in days (and the implementation going to
probably have some inevitable bugs), switching supported Python
implementation (or doing any major refactorings, to say) is a very bad
idea.  This is going to once again cause a horrible backwards
compatibility problem loop where people wouldn't be able to use EAPI 7
because they would need to provide means to upgrade Python and its
dependencies first, in order to be able to upgrade Portage.

-- 
Best regards,
Michał Górny

Re: [gentoo-project] For next council meeting: moving Portage to python3.6+

[nado]

April 25, 2018 8:56 AM, "Michał Górny" <mgorny@gentoo.org> wrote:

> W dniu śro, 18.04.2018 o godzinie 08∶58 -0700, użytkownik Zac Medico
> napisał:
> 
> Removing support for Python 2.7 is going to be a major drawback for our
> users. I am not even going to consider those who intentionally reduce
> their systems to 2.7 only for one reason or another. However, 2.7 has
> been the Gentoo's 'LTS' so far -- different versions of Python 3 come
> and go but 2.7 was there for a very long time to ease the transition.
> Only recently one of the developers had to solve hard upgrade conflicts
> and the simplest way of doing that was to unmerge Python 3 and use
> Python 2.7 to install a new version.

I think that workaround is even more common when you have to update some really old install.
I've experienced it two times with Gentoo over the last 5 years, first time was my fault, I messed
up my system, and the other is for serously outdated scaleway images [1].
It happens and I agree on keeping 2.7 support for a bit longer.

> With EAPI 7 approaching in days (and the implementation going to
> probably have some inevitable bugs), switching supported Python
> implementation (or doing any major refactorings, to say) is a very bad
> idea. This is going to once again cause a horrible backwards
> compatibility problem loop where people wouldn't be able to use EAPI 7
> because they would need to provide means to upgrade Python and its
> dependencies first, in order to be able to upgrade Portage.

I agree with this, I'd like to see changes coming nicely separated, not in a bunch and be left
determining why I can't upgrade my old system anymore.

[1] https://github.com/scaleway/image-gentoo/issues/8#issuecomment-343210153

--
Corentin “Nado” Pazdera

Re: [gentoo-project] For next council meeting: moving Portage to python3.6+

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 730 bytes --]

On 04/24/2018 11:56 PM, Michał Górny wrote:
> With EAPI 7 approaching in days (and the implementation going to
> probably have some inevitable bugs), switching supported Python
> implementation (or doing any major refactorings, to say) is a very bad
> idea.  This is going to once again cause a horrible backwards
> compatibility problem loop where people wouldn't be able to use EAPI 7
> because they would need to provide means to upgrade Python and its
> dependencies first, in order to be able to upgrade Portage.

I'm perfectly happy keeping the python2.7 support around for a few more
years. Some people seem pretty eager to stop supporting it, but I'd love
to hear some specific reasons.
-- 
Thanks,
Zac


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] For next council meeting: moving Portage to python3.6+

[Raymond Jennings]

On Wed, Apr 25, 2018 at 2:29 AM,  <nado@troglodyte.be> wrote:
> April 25, 2018 8:56 AM, "Michał Górny" <mgorny@gentoo.org> wrote:
>
>> W dniu śro, 18.04.2018 o godzinie 08∶58 -0700, użytkownik Zac Medico
>> napisał:
>>
>> Removing support for Python 2.7 is going to be a major drawback for our
>> users. I am not even going to consider those who intentionally reduce
>> their systems to 2.7 only for one reason or another. However, 2.7 has
>> been the Gentoo's 'LTS' so far -- different versions of Python 3 come
>> and go but 2.7 was there for a very long time to ease the transition.
>> Only recently one of the developers had to solve hard upgrade conflicts
>> and the simplest way of doing that was to unmerge Python 3 and use
>> Python 2.7 to install a new version.
>
> I think that workaround is even more common when you have to update some really old install.
> I've experienced it two times with Gentoo over the last 5 years, first time was my fault, I messed
> up my system, and the other is for serously outdated scaleway images [1].
> It happens and I agree on keeping 2.7 support for a bit longer.
>
>> With EAPI 7 approaching in days (and the implementation going to
>> probably have some inevitable bugs), switching supported Python
>> implementation (or doing any major refactorings, to say) is a very bad
>> idea. This is going to once again cause a horrible backwards
>> compatibility problem loop where people wouldn't be able to use EAPI 7
>> because they would need to provide means to upgrade Python and its
>> dependencies first, in order to be able to upgrade Portage.
>
> I agree with this, I'd like to see changes coming nicely separated, not in a bunch and be left
> determining why I can't upgrade my old system anymore.

I might have misread this, but isn't it policy that Gentoo doesn't
support upgrades of systems more than a year old?

I think it was said that if you go a year without updating, you aren't
supported anymore and you need to just do a fresh install.

Does anyone have any commentary on this?  Even to tell me that I'm mistaken?
>
> [1] https://github.com/scaleway/image-gentoo/issues/8#issuecomment-343210153
>
> --
> Corentin “Nado” Pazdera
>