1 |
On Sun, Apr 29, 2012 at 08:47:27AM +0200, Micha?? G??rny wrote: |
2 |
> On Sat, 28 Apr 2012 20:13:41 -0700 |
3 |
> Brian Harring <ferringb@×××××.com> wrote: |
4 |
> |
5 |
> > On Sat, Apr 28, 2012 at 12:26:41PM +0200, Ulrich Mueller wrote: |
6 |
> > > >>>>> On Sat, 28 Apr 2012, Ciaran McCreesh wrote: |
7 |
> > > |
8 |
> > > > On Sat, 28 Apr 2012 12:11:38 +0200 |
9 |
> > > > Ulrich Mueller <ulm@g.o> wrote: |
10 |
> > > >> >>>>> On Sat, 28 Apr 2012, Ciaran McCreesh wrote: |
11 |
> > > >> >> > * Get a versionator replacement into the PM |
12 |
> > > >> >> |
13 |
> > > >> >> Given the long time it's been in limbo I doubt that this will |
14 |
> > > >> >> be a quick feature. (But I'll be glad if you convince me of |
15 |
> > > >> >> the opposite.) |
16 |
> > > >> |
17 |
> > > >> > I thought we just didn't have that because we couldn't add new |
18 |
> > > >> > global scope functions. |
19 |
> > > >> |
20 |
> > > >> But can we already for EAPI 5? Wouldn't the following: |
21 |
> > > >> |
22 |
> > > >> EAPI=5 |
23 |
> > > >> MY_PV=$(new_pm_version_mangler_function ${PV}) |
24 |
> > > >> |
25 |
> > > >> still fail for old package managers that don't implement EAPI |
26 |
> > > >> parsing? |
27 |
> > > |
28 |
> > > > Didn't the Council effectively vote to ignore that problem? |
29 |
> > > |
30 |
> > > Yes, but after some reasonable transition period. |
31 |
> > |
32 |
> > <insert my ongoing "Gee, lovely fucking approach to designing a |
33 |
> > compatibility mechanism"/> |
34 |
> > |
35 |
> > For EAPI5, all global scope functionality/bash version/take your pick |
36 |
> > has to be taken off the table, and held back till EAPI6- w/ the |
37 |
> > timeline for EAPI6 being "a reasonable transition period" after EAPI5 |
38 |
> > has been stabled in portage. |
39 |
> |
40 |
> Usually, the transition period ends when we no longer bikeshed |
41 |
> the topic. |
42 |
|
43 |
Future suggestion: if you're going to try and be a smart ass, do it |
44 |
when you're right. Not even sure how you could comment on transition |
45 |
periods since the last time this occured was in '06, but hey, have at |
46 |
it. |
47 |
|
48 |
|
49 |
Continuing the point (w/ specific details so mgorny actually listens |
50 |
this time), referring to |
51 |
http://wiki.gentoo.org/wiki/Alternate_EAPI_mechanisms , |
52 |
the rules were to be "deploy the EAPI parsing, don't break existing |
53 |
mechanism for <reasonable transition period>, then go nuts". |
54 |
|
55 |
|
56 |
So... if we abide by what was actually voted upon, our options are as |
57 |
follows: |
58 |
|
59 |
1) No global scope crap in EAPI5. Land it in EAPI6 since that's |
60 |
likely going to land past the compatibility window. This is what I |
61 |
stated above; it sucks, but welcome to compatibility. |
62 |
|
63 |
2) Stable a portage w/ the parsing now, delay EAPI5 till the |
64 |
compatibility window is over. This sucks worse than #1 in my view. |
65 |
|
66 |
3) Decide we don't actually care about compatibility (despite the |
67 |
proposal being about *compatibility*), and just deploy global crap in |
68 |
EAPI5 and ignore compatibility related breakage. Smugly label anyone |
69 |
bringing these issues up as bikeshedding, eventually comparing them to |
70 |
ciaran. |
71 |
|
72 |
So... bikeshed about the options, but we choose one of them. |
73 |
|
74 |
~brian |