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

[Michał Górny]

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@g.o> 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