1 |
On Sun, 17 May 2009 20:40:41 +0000 (UTC) |
2 |
Duncan <1i5t5.duncan@×××.net> wrote: |
3 |
|
4 |
> Ryan Hill <dirtyepic@g.o> posted |
5 |
> 20090517111152.133c7280@×××××××××××××××××.ca, excerpted below, on Sun, 17 |
6 |
> May 2009 11:11:52 -0600: |
7 |
> |
8 |
> >> Do we want to document the following? (do we have already?) - When is |
9 |
> >> it allowed to use an EAPI in the tree (given as offset to the release |
10 |
> >> of portage supporting that eapi) - When is it allowed to use an EAPI in |
11 |
> >> the stable tree (given as offset of when a portage version supporting |
12 |
> >> that EAPI got stable) |
13 |
> > |
14 |
> > As soon as a version of portage supporting that EAPI is available. |
15 |
> |
16 |
> That's a dangerous position to take. See "experimental" EAPIs for |
17 |
> instance, sometimes temporarily supported by portage, but NOT for use in |
18 |
> the tree. |
19 |
> |
20 |
> But I think you knew that and simply made some assumptions with the |
21 |
> statement that not all readers may have. |
22 |
|
23 |
Yes, viewers at home, I'm speaking technically not politically. Technically |
24 |
you could add ebuilds for any EAPI the PM supports to the tree without |
25 |
affecting users. Politically, your fellow developers would stone you to |
26 |
death, put you in a sack, and drop you to the bottom of the sea. They might |
27 |
even revoke your commit access too. |
28 |
|
29 |
|
30 |
-- |
31 |
gcc-porting, by design, by neglect |
32 |
treecleaner, for a fact or just for effect |
33 |
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |