[gentoo-dev] [RFC] Deadlines for next Python implementations

[gentoo-dev] [RFC] Deadlines for next Python implementations

[Michał Górny]

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

Hi, everyone.

I'd like to be more proactive in avoiding the mess like Python 3.6->3.7
switch were.  For this reason, I think it would be better to set
and publish some early deadlines.  Even if we aren't going to strictly
keep to them, it would help people realize how much time there is left
to finish the preparations.


Python 3.6→3.7 migration
========================
We've already switched the profiles but there are still some unmigrated
packages.  We will continue either migrating them or last riting if
migration seems unlikely to happen.  Nevertheless, it is wortwhile to
set some final deadlines.  My proposal is:


2020-08-01  Python 3.7 migration deadline

   After this date, we lastrite all remaining packages that haven't been
   ported.  This gives people roughly two months, with a ping one month
   from now.

2020-09-15  Python 3.6 target removal

   As usual, the interpreter will be kept a bit longer, then moved to
   ::python.  This accounts for some extra time if people decide to
   recover last rited packages last minute.


Python 3.7→3.8 migration
========================
The interpreter is stable but there's still lot of migration work to be
done.  Good news is that because of the delay with 3.7, many packages
are getting 3.7+3.8 or even 3.7+3.8+3.9 simultaneously, so there will be
less work in the future.


2020-07-01  Python 3.8 target stable-unmasking goal

   This is not really a deadline but I'd like to aim for resolving
   depgraph issues and stabilizing everything needed to unmask python3_7
   target on stable.  Initial set of stablereqs was filed already, 
   and we'll be unmasking the target as soon as the depgraph is clean.

2020-09-01  Python 3.8 migration warning

   At this point we tell people it's about time to start actively
   updating their packages.

2020-12-01  Python 3.8 migration deadline

   We lastrite all the unmigrated packages.

2021-01-15  Python 3.7 target removal

   As above.


Python 2.7 removal
==================
I would like to continue removing py2.7 from packages where possible,
and slowly lastriting where clearly impossible.  However,
for the remaining packages I'd like to set a hard deadline.


2021-01-01  Final Python 2.7 deadline

   That's one year after upstream's EOL.  At this point, we last rite
   all the remaining py2.7 packages.

2021-02-15  Python 2.7 target removal

   All packages relying on the target are removed.  The interpreter
   stays for as long as we need it.


General goal
============
As a general goal, I'd like to set timelines like this once we decide
that the next interpreter goes stable.  The exact lengths are highly
dependent on properties of the next target.  For example, I suspect
Python 3.9 will be easier for us; so far my testing has shown issues
that are rather easy to solve.


Combined timeline
=================
From the above dates:

            2.7 3.6 3.7 3.8
2020-07-01   |   |   |   u    py3.8 target unmasked
             |   |   |   |
2020-08-01   |   m   |   |    py3.6 pkg last rites
             |   |   |   |
2020-09-01   |   |   |   w    py3.7→3.8 migr. warning
2020-09-15   |   x   |   |    py3.6 pkg removal
             |       |   |
             |       |   |
             |       |   |
             |       |   |
             |       |   |
2020-12-01   |       m   |    py3.7 pkg last rites
             |       |   |
2021-01-01   m       |   |    py2.7 pkg last rites
2021-01-15   |       x   |    py3.7 pkg removal
             |           |
2021-02-15   x           |    py2.7 pkg removal
                         v


WDYT?


-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [RFC] Deadlines for next Python implementations

[Patrick McLean]

On Mon, 01 Jun 2020 22:27:19 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> Hi, everyone.
> 
> I'd like to be more proactive in avoiding the mess like Python 3.6->3.7
> switch were.  For this reason, I think it would be better to set
> and publish some early deadlines.  Even if we aren't going to strictly
> keep to them, it would help people realize how much time there is left
> to finish the preparations.
> 
> 
> Python 3.6→3.7 migration
> ========================
> We've already switched the profiles but there are still some unmigrated
> packages.  We will continue either migrating them or last riting if
> migration seems unlikely to happen.  Nevertheless, it is wortwhile to
> set some final deadlines.  My proposal is:
> 
> 
> 2020-08-01  Python 3.7 migration deadline
> 
>    After this date, we lastrite all remaining packages that haven't been
>    ported.  This gives people roughly two months, with a ping one month
>    from now.
> 
> 2020-09-15  Python 3.6 target removal
> 
>    As usual, the interpreter will be kept a bit longer, then moved to
>    ::python.  This accounts for some extra time if people decide to
>    recover last rited packages last minute.

Given that 2020-08-15 is still well over a year before the upstream EOL,
this might be a little premature. How about we the deprecation dates back
by 4 months? We can still have a similar schedule, just a little later. That
way we are deprecating 3.6 less than a year before the EOL upstream.

We can keep the 2.7 removal as-is.

> 
> Python 3.7→3.8 migration
> ========================
> The interpreter is stable but there's still lot of migration work to be
> done.  Good news is that because of the delay with 3.7, many packages
> are getting 3.7+3.8 or even 3.7+3.8+3.9 simultaneously, so there will be
> less work in the future.
> 
> 
> 2020-07-01  Python 3.8 target stable-unmasking goal
> 
>    This is not really a deadline but I'd like to aim for resolving
>    depgraph issues and stabilizing everything needed to unmask python3_7
>    target on stable.  Initial set of stablereqs was filed already, 
>    and we'll be unmasking the target as soon as the depgraph is clean.
> 
> 2020-09-01  Python 3.8 migration warning
> 
>    At this point we tell people it's about time to start actively
>    updating their packages.

Under my suggested timeline, I would say we do this 2020-12-01.

> 2020-12-01  Python 3.8 migration deadline
> 
>    We lastrite all the unmigrated packages.

This could be pushed back to 2020-05-01 to not be too close to the 3.6
removal. I personally do not have any strong feelings either way about
3.7, so I would be fine removing 3.6 and 3.7 at the same time if that
is easier.

> 2021-01-15  Python 3.7 target removal
> 
>    As above.
> 
> 
> Python 2.7 removal
> ==================
> I would like to continue removing py2.7 from packages where possible,
> and slowly lastriting where clearly impossible.  However,
> for the remaining packages I'd like to set a hard deadline.
> 
> 
> 2021-01-01  Final Python 2.7 deadline
> 
>    That's one year after upstream's EOL.  At this point, we last rite
>    all the remaining py2.7 packages.
> 
> 2021-02-15  Python 2.7 target removal
> 
>    All packages relying on the target are removed.  The interpreter
>    stays for as long as we need it.
> 
> 
> General goal
> ============
> As a general goal, I'd like to set timelines like this once we decide
> that the next interpreter goes stable.  The exact lengths are highly
> dependent on properties of the next target.  For example, I suspect
> Python 3.9 will be easier for us; so far my testing has shown issues
> that are rather easy to solve.
> 

Here is an attempt at updating version of ASCII art, from what
I can tell, the 'w' at the 3.7->3.8 warning probably belonged
in the 3.7 column, I moved it. As I said above, I am personally
fine if we make 3.6 and 3.7 removals close together (even at
the same time).

Combined timeline
=================
From the above dates:

            2.7 3.6 3.7 3.8
2020-07-01   |   |   |   u    py3.8 target unmasked
             |   |   |   |
             |   |   |   |
             |   |   |   |
             |   |   |   |
             |   |   |   |
             |   |   |   |
2020-12-01   |   |   w   |    py3.7→3.8 migr. warning
             |   |   |   |
             |   |   |   |
2021-01-01   m   |   |   |    py2.7 pkg last rites
             |   |   |   |
             |   |   |   |
2021-02-01   |   m   |   |    py3.6 pkg last rites
             |   |   |   |
2021-02-15   x   |   |   |    py2.7 pkg removal
2021-03-15       x   |   |    py3.6 pkg removal
                     |   |
                     |   |
                     |   |
2021-05-01           m   |    py3.7 pkg last rites
                     |   |
                     |   |
2021-06-15           x   |    py3.7 pkg removal
                         |
                         v

Re: [gentoo-dev] [RFC] Deadlines for next Python implementations

[Michał Górny]

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

On Mon, 2020-06-01 at 13:34 -0700, Patrick McLean wrote:
> On Mon, 01 Jun 2020 22:27:19 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > Hi, everyone.
> > 
> > I'd like to be more proactive in avoiding the mess like Python 3.6->3.7
> > switch were.  For this reason, I think it would be better to set
> > and publish some early deadlines.  Even if we aren't going to strictly
> > keep to them, it would help people realize how much time there is left
> > to finish the preparations.
> > 
> > 
> > Python 3.6→3.7 migration
> > ========================
> > We've already switched the profiles but there are still some unmigrated
> > packages.  We will continue either migrating them or last riting if
> > migration seems unlikely to happen.  Nevertheless, it is wortwhile to
> > set some final deadlines.  My proposal is:
> > 
> > 
> > 2020-08-01  Python 3.7 migration deadline
> > 
> >    After this date, we lastrite all remaining packages that haven't been
> >    ported.  This gives people roughly two months, with a ping one month
> >    from now.
> > 
> > 2020-09-15  Python 3.6 target removal
> > 
> >    As usual, the interpreter will be kept a bit longer, then moved to
> >    ::python.  This accounts for some extra time if people decide to
> >    recover last rited packages last minute.
> 
> Given that 2020-08-15 is still well over a year before the upstream EOL,
> this might be a little premature. How about we the deprecation dates back
> by 4 months? We can still have a similar schedule, just a little later. That
> way we are deprecating 3.6 less than a year before the EOL upstream.
> 
> We can keep the 2.7 removal as-is.

I don't mind shifting the removal.

> 
> > Python 3.7→3.8 migration
> > ========================
> > The interpreter is stable but there's still lot of migration work to be
> > done.  Good news is that because of the delay with 3.7, many packages
> > are getting 3.7+3.8 or even 3.7+3.8+3.9 simultaneously, so there will be
> > less work in the future.
> > 
> > 
> > 2020-07-01  Python 3.8 target stable-unmasking goal
> > 
> >    This is not really a deadline but I'd like to aim for resolving
> >    depgraph issues and stabilizing everything needed to unmask python3_7
> >    target on stable.  Initial set of stablereqs was filed already, 
> >    and we'll be unmasking the target as soon as the depgraph is clean.
> > 
> > 2020-09-01  Python 3.8 migration warning
> > 
> >    At this point we tell people it's about time to start actively
> >    updating their packages.
> 
> Under my suggested timeline, I would say we do this 2020-12-01.

...but I do mind this.  Python 3.8 is something we should very soon,
and waiting another 6 months to tell people to start testing will just
make it into another mess like Python 3.7 were.

> > 2020-12-01  Python 3.8 migration deadline
> > 
> >    We lastrite all the unmigrated packages.
> 
> This could be pushed back to 2020-05-01 to not be too close to the 3.6
> removal. I personally do not have any strong feelings either way about
> 3.7, so I would be fine removing 3.6 and 3.7 at the same time if that
> is easier.

I would actually prefer pushing for 3.8 earlier and removing them
at the same time.  If anything, this would let people who haven't moved
off 3.6 yet go straight to 3.8 without having them do another update
in a few months.

> > 2021-01-15  Python 3.7 target removal
> > 
> >    As above.
> > 
> > 
> > Python 2.7 removal
> > ==================
> > I would like to continue removing py2.7 from packages where possible,
> > and slowly lastriting where clearly impossible.  However,
> > for the remaining packages I'd like to set a hard deadline.
> > 
> > 
> > 2021-01-01  Final Python 2.7 deadline
> > 
> >    That's one year after upstream's EOL.  At this point, we last rite
> >    all the remaining py2.7 packages.
> > 
> > 2021-02-15  Python 2.7 target removal
> > 
> >    All packages relying on the target are removed.  The interpreter
> >    stays for as long as we need it.
> > 
> > 
> > General goal
> > ============
> > As a general goal, I'd like to set timelines like this once we decide
> > that the next interpreter goes stable.  The exact lengths are highly
> > dependent on properties of the next target.  For example, I suspect
> > Python 3.9 will be easier for us; so far my testing has shown issues
> > that are rather easy to solve.
> > 
> 
> Here is an attempt at updating version of ASCII art, from what
> I can tell, the 'w' at the 3.7->3.8 warning probably belonged
> in the 3.7 column, I moved it.

Thanks.

>  As I said above, I am personally
> fine if we make 3.6 and 3.7 removals close together (even at
> the same time).
> 
> Combined timeline
> =================
> From the above dates:
> 
>             2.7 3.6 3.7 3.8
> 2020-07-01   |   |   |   u    py3.8 target unmasked
>              |   |   |   |
>              |   |   |   |
>              |   |   |   |
>              |   |   |   |
>              |   |   |   |
>              |   |   |   |
> 2020-12-01   |   |   w   |    py3.7→3.8 migr. warning
>              |   |   |   |
>              |   |   |   |
> 2021-01-01   m   |   |   |    py2.7 pkg last rites
>              |   |   |   |
>              |   |   |   |
> 2021-02-01   |   m   |   |    py3.6 pkg last rites
>              |   |   |   |
> 2021-02-15   x   |   |   |    py2.7 pkg removal
> 2021-03-15       x   |   |    py3.6 pkg removal
>                      |   |
>                      |   |
>                      |   |
> 2021-05-01           m   |    py3.7 pkg last rites
>                      |   |
>                      |   |
> 2021-06-15           x   |    py3.7 pkg removal
>                          |
>                          v
> 
> 

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [RFC] Deadlines for next Python implementations

[Patrick McLean]

On Mon, 01 Jun 2020 23:04:38 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Mon, 2020-06-01 at 13:34 -0700, Patrick McLean wrote:
> > On Mon, 01 Jun 2020 22:27:19 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> >   
> > > Hi, everyone.
> > > 
> > > I'd like to be more proactive in avoiding the mess like Python 3.6->3.7
> > > switch were.  For this reason, I think it would be better to set
> > > and publish some early deadlines.  Even if we aren't going to strictly
> > > keep to them, it would help people realize how much time there is left
> > > to finish the preparations.
> > > 
> > > 
> > > Python 3.6→3.7 migration
> > > ========================
> > > We've already switched the profiles but there are still some unmigrated
> > > packages.  We will continue either migrating them or last riting if
> > > migration seems unlikely to happen.  Nevertheless, it is wortwhile to
> > > set some final deadlines.  My proposal is:
> > > 
> > > 
> > > 2020-08-01  Python 3.7 migration deadline
> > > 
> > >    After this date, we lastrite all remaining packages that haven't been
> > >    ported.  This gives people roughly two months, with a ping one month
> > >    from now.
> > > 
> > > 2020-09-15  Python 3.6 target removal
> > > 
> > >    As usual, the interpreter will be kept a bit longer, then moved to
> > >    ::python.  This accounts for some extra time if people decide to
> > >    recover last rited packages last minute.  
> > 
> > Given that 2020-08-15 is still well over a year before the upstream EOL,
> > this might be a little premature. How about we the deprecation dates back
> > by 4 months? We can still have a similar schedule, just a little later. That
> > way we are deprecating 3.6 less than a year before the EOL upstream.
> > 
> > We can keep the 2.7 removal as-is.  
> 
> I don't mind shifting the removal.
> 
> >   
> > > Python 3.7→3.8 migration
> > > ========================
> > > The interpreter is stable but there's still lot of migration work to be
> > > done.  Good news is that because of the delay with 3.7, many packages
> > > are getting 3.7+3.8 or even 3.7+3.8+3.9 simultaneously, so there will be
> > > less work in the future.
> > > 
> > > 
> > > 2020-07-01  Python 3.8 target stable-unmasking goal
> > > 
> > >    This is not really a deadline but I'd like to aim for resolving
> > >    depgraph issues and stabilizing everything needed to unmask python3_7
> > >    target on stable.  Initial set of stablereqs was filed already, 
> > >    and we'll be unmasking the target as soon as the depgraph is clean.
> > > 
> > > 2020-09-01  Python 3.8 migration warning
> > > 
> > >    At this point we tell people it's about time to start actively
> > >    updating their packages.  
> > 
> > Under my suggested timeline, I would say we do this 2020-12-01.  
> 
> ...but I do mind this.  Python 3.8 is something we should very soon,
> and waiting another 6 months to tell people to start testing will just
> make it into another mess like Python 3.7 were.

That's fine with me, I don't mind having a warning about packages not
migrated to 3.8 earlier. I just would to keep 3.6 around for until next
year to give us a little more time to migrate.

> > > 2020-12-01  Python 3.8 migration deadline
> > > 
> > >    We lastrite all the unmigrated packages.  
> > 
> > This could be pushed back to 2020-05-01 to not be too close to the 3.6
> > removal. I personally do not have any strong feelings either way about
> > 3.7, so I would be fine removing 3.6 and 3.7 at the same time if that
> > is easier.  
> 
> I would actually prefer pushing for 3.8 earlier and removing them
> at the same time.  If anything, this would let people who haven't moved
> off 3.6 yet go straight to 3.8 without having them do another update
> in a few months.

That's fine with me. We are actually taking this approach, skipping 3.7
entirely any moving directly to 3.8.

> > > 2021-01-15  Python 3.7 target removal
> > > 
> > >    As above.
> > > 
> > > 
> > > Python 2.7 removal
> > > ==================
> > > I would like to continue removing py2.7 from packages where possible,
> > > and slowly lastriting where clearly impossible.  However,
> > > for the remaining packages I'd like to set a hard deadline.
> > > 
> > > 
> > > 2021-01-01  Final Python 2.7 deadline
> > > 
> > >    That's one year after upstream's EOL.  At this point, we last rite
> > >    all the remaining py2.7 packages.
> > > 
> > > 2021-02-15  Python 2.7 target removal
> > > 
> > >    All packages relying on the target are removed.  The interpreter
> > >    stays for as long as we need it.
> > > 
> > > 
> > > General goal
> > > ============
> > > As a general goal, I'd like to set timelines like this once we decide
> > > that the next interpreter goes stable.  The exact lengths are highly
> > > dependent on properties of the next target.  For example, I suspect
> > > Python 3.9 will be easier for us; so far my testing has shown issues
> > > that are rather easy to solve.
> > >   
> > 
> > Here is an attempt at updating version of ASCII art, from what
> > I can tell, the 'w' at the 3.7->3.8 warning probably belonged
> > in the 3.7 column, I moved it.  
> 
> Thanks.
> 
> >  As I said above, I am personally
> > fine if we make 3.6 and 3.7 removals close together (even at
> > the same time).
> > 
> > Combined timeline
> > =================
> > From the above dates:
> > 
> >             2.7 3.6 3.7 3.8
> > 2020-07-01   |   |   |   u    py3.8 target unmasked
> >              |   |   |   |
> >              |   |   |   |
> >              |   |   |   |
> >              |   |   |   |
> >              |   |   |   |
> >              |   |   |   |
> > 2020-12-01   |   |   w   |    py3.7→3.8 migr. warning
> >              |   |   |   |
> >              |   |   |   |
> > 2021-01-01   m   |   |   |    py2.7 pkg last rites
> >              |   |   |   |
> >              |   |   |   |
> > 2021-02-01   |   m   |   |    py3.6 pkg last rites
> >              |   |   |   |
> > 2021-02-15   x   |   |   |    py2.7 pkg removal
> > 2021-03-15       x   |   |    py3.6 pkg removal
> >                      |   |
> >                      |   |
> >                      |   |
> > 2021-05-01           m   |    py3.7 pkg last rites
> >                      |   |
> >                      |   |
> > 2021-06-15           x   |    py3.7 pkg removal
> >                          |
> >                          v
> > 
> >   
> 
> -- 
> Best regards,
> Michał Górny
> 

Re: [gentoo-dev] [RFC] Deadlines for next Python implementations

[Matthias Maier]

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


On Mon, Jun  1, 2020, at 15:27 CDT, Michał Górny <mgorny@gentoo.org> wrote:

> 2020-08-01  Python 3.7 migration deadline
>
>    After this date, we lastrite all remaining packages that haven't been
>    ported.  This gives people roughly two months, with a ping one month
>    from now.

> [...]

> 2020-12-01  Python 3.8 migration deadline
>
>    We lastrite all the unmigrated packages.

Most of the time (guess >99%) this "porting" simply consists of
"keywording" with the new python target, i.e., a one-line change in the
ebuild.

What about we "auto keyword" all remaining packages that have a
python3_6 target but lack the python3_7 target instead? Meaning, just
add the python3_7 value to the corresponding PYTHON_*TARGET.

Given the fact how little difference there is between python3_6 and
python3_7 this seems to be the appropriate, gentler approach here.

Same for python3_8.

Best,
Matthias

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 850 bytes --]

Re: [gentoo-dev] [RFC] Deadlines for next Python implementations

[Michał Górny]

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

On Mon, 2020-06-01 at 15:49 -0500, Matthias Maier wrote:
> On Mon, Jun  1, 2020, at 15:27 CDT, Michał Górny <mgorny@gentoo.org> wrote:
> 
> > 2020-08-01  Python 3.7 migration deadline
> > 
> >    After this date, we lastrite all remaining packages that haven't been
> >    ported.  This gives people roughly two months, with a ping one month
> >    from now.
> > [...]
> > 2020-12-01  Python 3.8 migration deadline
> > 
> >    We lastrite all the unmigrated packages.
> 
> Most of the time (guess >99%) this "porting" simply consists of
> "keywording" with the new python target, i.e., a one-line change in the
> ebuild.
> 
> What about we "auto keyword" all remaining packages that have a
> python3_6 target but lack the python3_7 target instead? Meaning, just
> add the python3_7 value to the corresponding PYTHON_*TARGET.
> 
> Given the fact how little difference there is between python3_6 and
> python3_7 this seems to be the appropriate, gentler approach here.
> 

Most of these packages are unmaintained, seriously outdated and they may
actually be broken with py3.7 (because they're so seriously outdated). 
I don't see that as solving a problem, it merely shoves it under
the carpet and leaves us with the same shove-under-the-carpet attitude
for the next few years.

I like to think of these migrations as opportunity to fix some broken
ebuilds, update some packages and last rite all the things that aren't
maintained.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [RFC] Deadlines for next Python implementations

[Aaron Bauman]

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

On Mon, Jun 01, 2020 at 11:07:39PM +0200, Michał Górny wrote:
> On Mon, 2020-06-01 at 15:49 -0500, Matthias Maier wrote:
> > On Mon, Jun  1, 2020, at 15:27 CDT, Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > > 2020-08-01  Python 3.7 migration deadline
> > > 
> > >    After this date, we lastrite all remaining packages that haven't been
> > >    ported.  This gives people roughly two months, with a ping one month
> > >    from now.
> > > [...]
> > > 2020-12-01  Python 3.8 migration deadline
> > > 
> > >    We lastrite all the unmigrated packages.
> > 
> > Most of the time (guess >99%) this "porting" simply consists of
> > "keywording" with the new python target, i.e., a one-line change in the
> > ebuild.
> > 
> > What about we "auto keyword" all remaining packages that have a
> > python3_6 target but lack the python3_7 target instead? Meaning, just
> > add the python3_7 value to the corresponding PYTHON_*TARGET.
> > 
> > Given the fact how little difference there is between python3_6 and
> > python3_7 this seems to be the appropriate, gentler approach here.
> > 
> 
> Most of these packages are unmaintained, seriously outdated and they may
> actually be broken with py3.7 (because they're so seriously outdated). 
> I don't see that as solving a problem, it merely shoves it under
> the carpet and leaves us with the same shove-under-the-carpet attitude
> for the next few years.
> 
> I like to think of these migrations as opportunity to fix some broken
> ebuilds, update some packages and last rite all the things that aren't
> maintained.
> 

Couldn't agree more here. Unfortunately, it is normally the big projects
that have to deal with cleaning up the cruft.

> -- 
> Best regards,
> Michał Górny
> 

-- 
Cheers,
Aaron

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [RFCv2] Deadlines for next Python implementations

[Michał Górny]

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

So v2, taking Patrick's requests into consideration:

            2.7 3.6 3.7 3.8
2020-07-01   |   |   |   u    py3.8 target unmasked
             |   |   |   |
             |   |   |   |
             |   |   |   |
2020-09-01   |   |   w   |    py3.7→3.8 migr. warning
             |   |   |   |
             |   |   |   |
             |   |   |   |
             |   |   |   |
             |   |   |   |
2020-12-01   |   |   |   s    rough py3.8 switch date
             |   |   |   |
2021-01-01   m   m   |   |    py2.7+3.6 pkg last rites
             |   |   |   |
             |   |   |   |
2021-02-15   x   x   |   |    py2.7+3.6 pkg removal
                     |   |
                     |   |
                     |   |
                     |   |
2021-05-01           m   |    py3.7 pkg last rites
                     |   |
                     |   |
2021-06-15           x   |    py3.7 pkg removal
                         |
                         v

Changes:

- py2.7 and py3.6 are removed simultaneously to reduce rebuilds

- py3.7 removal postponed another half a year

- added a rough switch date to py3.8 half a year before py3.7 removal


-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]