On Mon, 01 Jun 2020 23:04:38 +0200 Michał Górny <mgo...@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 <mgo...@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 >
