1 |
On Wed, 2021-03-03 at 23:00 +0000, Sam James wrote: |
2 |
> > On 2 Mar 2021, at 15:05, Michał Górny <mgorny@g.o> wrote: |
3 |
> > |
4 |
> > Hi, |
5 |
> > |
6 |
> > I think I've made a mistake by stabilizing PyPy(3), and I would like |
7 |
> > to |
8 |
> > drop it back to ~arch (and stable-mask the relevant flags). |
9 |
> > |
10 |
> > Roughly, there are 4 problems with it: |
11 |
> > |
12 |
> > [snip] |
13 |
> |
14 |
> > Honestly, I've tried to improve PyPy in the past but I don't really |
15 |
> > have |
16 |
> > time or motivation to do this continuously. PyPy is an interesting |
17 |
> > project, and it has its isolated uses. However, I don't think it's |
18 |
> > ready as a general-purpose Python interpreter for production |
19 |
> > environments. |
20 |
> > |
21 |
> > I don't really want to remove it entirely or revert all the work |
22 |
> > we've |
23 |
> > put into testing packages with it -- but I think we should move it |
24 |
> > to |
25 |
> > ~arch at the very least. |
26 |
> |
27 |
> It’s unfortunate but no objections. News item may be worthwhile |
28 |
> to explain to users why & how for posterity, but not necessary. |
29 |
|
30 |
Yeah, I'm still not sure what to do. |
31 |
|
32 |
What is certain is that we need to do something because current PyPy |
33 |
versions are vulnerable, and two-slots-in-one-target approach is not |
34 |
sustainable. |
35 |
|
36 |
Option 1. is to stabilize the new versions, including alpha pypy3.7 |
37 |
(test-restricted). This will make it possible to delay the final |
38 |
decision. However, it would imply that stable users rebuild everything |
39 |
to upgrade pypy3 and that would suck if it would mean it goes ~arch |
40 |
anyway. |
41 |
|
42 |
Option 2. is to drop it to ~arch. This feels better given its quality |
43 |
but kinda sucks for users. |
44 |
|
45 |
When we remove py3.7, having pypy3.7 as the newest pypy will be the same |
46 |
kind of problem whether it's stable or not. |
47 |
|
48 |
-- |
49 |
Best regards, |
50 |
Michał Górny |