1 |
On Tue, 2009-05-26 at 20:57 +0200, Tiziano Müller wrote: |
2 |
> This is your friendly reminder! Same bat time (typically the 2nd & 4th |
3 |
> Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ |
4 |
> irc.freenode.net) ! |
5 |
> |
6 |
> If you have something you'd wish for us to chat about, maybe even vote |
7 |
> on, let us know! Simply reply to this e-mail for the whole Gentoo dev |
8 |
> list to see. |
9 |
> |
10 |
> For more info on the Gentoo Council, feel free to browse our homepage: |
11 |
> http://www.gentoo.org/proj/en/council/ |
12 |
> |
13 |
> |
14 |
> Following is the preliminary meeting agenda. First we'll have to fill |
15 |
> the empty spot. After a short upgrade on EAPI-3 implementation we will |
16 |
> discuss the removal of old eclasses, followed by our old friend GLEP 55. |
17 |
> If we still have time we can dive into the topic of general EAPI |
18 |
> development. |
19 |
> |
20 |
|
21 |
Because Piotr recently amended GLEP55 to provide some further |
22 |
clarification and justification as well as to present a few alternatives |
23 |
addressing some objections people have expressed, it seems to me that |
24 |
the GLEP55 discussion should now go something like this: |
25 |
|
26 |
1. Approve the concept in principle (I think Piotr's examples |
27 |
sufficiently show the need for something along the lines set out in the |
28 |
revised GLEP); |
29 |
|
30 |
2. Choose one of the proposed solutions. For what it's worth, I favor |
31 |
the new extension (package.ebuild --> package.eb), and then I think |
32 |
something like ${PN}-${PVR}.eapi-${EAPI}.eb (or equivalent) is probably |
33 |
best. Here, ${PVR} is perhaps in a new version format. |
34 |
|
35 |
a. No introduced overhead; |
36 |
b. Current PMs will not even see it; |
37 |
c. I think there is an advantage for the users and developers to be |
38 |
able to see the required eapi immediately without having to read all |
39 |
the .eb (or .ebuild if you choose .ebuild-<EAPI>) files. |
40 |
|
41 |
3. Approve the GLEP. |
42 |
|
43 |
I would do the first quickly in order to cut off all the continual noise |
44 |
on gentoo-dev@, and I really think the revised GLEP makes the case for |
45 |
it well enough. After that, it should no longer be a religious issue, |
46 |
and I optimistically would not expect step 2 to take long at all. |
47 |
|
48 |
I note that the .eapi-${EAPI} part could well be optional, in which case |
49 |
GLEP54 falls naturally into the new scheme as something like |
50 |
${PN}-${PVR}-scm.eb |
51 |
|
52 |
|
53 |
> |
54 |
> Approval/voting of new council member replacing Donnie Berkholz |
55 |
> --------------------------------------------------------------- |
56 |
> |
57 |
> Unfortunately Donnie resigned as a member of the council (for |
58 |
> details please read his mail on the g-council ml). Next in line |
59 |
> are ulm and ssuominen. |
60 |
> |
61 |
> |
62 |
> EAPI 3: Short discussion of the progress |
63 |
> ---------------------------------------- |
64 |
> |
65 |
> zmedico will provide an update on the progress of the implementation. Short |
66 |
> discussion of problems and implementation decisions if needed. |
67 |
> |
68 |
> |
69 |
> Removing old eclasses |
70 |
> --------------------- |
71 |
> |
72 |
> Goal: Decide whether developers are allowed to remove eclasses. Problem: |
73 |
> Upgrading using portage with a version before 2.1.4 will fail since portage |
74 |
> always used eclasses from the tree instead of the ones from environment.bz2, |
75 |
> even though the environment fail has been generated. Portage 2.1.4 got stabled |
76 |
> over a year ago. |
77 |
> |
78 |
> |
79 |
> Handling EAPI versioning in a forwards-compatible way |
80 |
> ----------------------------------------------------- |
81 |
> |
82 |
> Goal: Discuss whether one of the alternatives given in GLEP 55 is appropriate |
83 |
> to solve the problem. Decide which one should be chosen. |
84 |
> |
85 |
> |
86 |
> Define EAPI development/deployment cycles |
87 |
> ----------------------------------------- |
88 |
> |
89 |
> Goal: Start discussion about EAPI development/deployment. For example: |
90 |
> Collect problems of eapi introductions in the past, like reverting |
91 |
> ebuilds to former eapis to get them stable, not waiting for the pm |
92 |
> support a certain eapi before requesting stable keywords for ebuilds |
93 |
> using the new eapi, .... Collect problems of EAPI development like |
94 |
> feature-freeze, late feature removals (due to implementation problems). |
95 |
> Eventually develop a lightweight EAPI development model. |
96 |
> |
97 |
> |
98 |
> Cheers, |
99 |
> Tiziano |
100 |
Regards, |
101 |
Ferris |
102 |
-- |
103 |
Ferris McCormick (P44646, MI) <fmccor@g.o> |
104 |
Developer, Gentoo Linux (Sparc, Userrel, Trustees) |