1 |
leio 09/11/11 00:14:00 |
2 |
|
3 |
Added: 20091109.txt |
4 |
Log: |
5 |
Add raw log from November 9th 2009 meeting |
6 |
|
7 |
Revision Changes Path |
8 |
1.1 xml/htdocs/proj/en/council/meeting-logs/20091109.txt |
9 |
|
10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20091109.txt?rev=1.1&view=markup |
11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20091109.txt?rev=1.1&content-type=text/plain |
12 |
|
13 |
Index: 20091109.txt |
14 |
=================================================================== |
15 |
21:00:03 <ulm> O.K., let's start |
16 |
21:00:05 --- ulm sets mode +m #gentoo-council |
17 |
21:00:13 * lu_zero murmurs things about xen-fullvirt and clock drifts |
18 |
21:00:22 --- ulm gives voice to DrEeevil |
19 |
21:00:32 <ulm> who's logging? |
20 |
21:00:42 <Betelgeuse> I do as usual |
21 |
21:00:44 <leio> Many probably are, me included |
22 |
21:00:59 <ulm> roll call |
23 |
21:01:03 <leio> here |
24 |
21:01:05 <Betelgeuse> \o/ |
25 |
21:01:06 * lu_zero here |
26 |
21:01:12 * dertobi123 yawns |
27 |
21:01:18 <DrEeevil> here, representing solar |
28 |
21:01:43 <Calchan> Im here |
29 |
21:02:26 <ulm> we have too many topics for 60 minutes, so is it o.k. if we extend to 90 min today? |
30 |
21:02:33 <Betelgeuse> yes |
31 |
21:02:39 <ulm> or has anybody to leave sooner? |
32 |
21:02:39 <leio> yes |
33 |
21:02:43 <lu_zero> ulm fine |
34 |
21:02:48 <leio> err, 90 minutes is OK |
35 |
21:02:54 <DrEeevil> ok |
36 |
21:02:56 <dertobi123> would be nice if we can make it within 60 minutes |
37 |
21:03:27 <ulm> dertobi123: "would be nice"? is this a veto? |
38 |
21:03:44 <Betelgeuse> dertobi123: unlikely |
39 |
21:03:48 <dertobi123> not a veto, just a "would be nice" |
40 |
21:03:52 <ulm> k |
41 |
21:04:02 <lu_zero> ulm I think the idea is to have the extension last the required time |
42 |
21:04:06 <Betelgeuse> but do try to be active so if we vote ulm doesn't have to wait etc |
43 |
21:04:07 <lu_zero> (less than 30 min) |
44 |
21:04:09 <Calchan> 90 minutes is KO here |
45 |
21:04:11 <Calchan> OK |
46 |
21:04:40 <ulm> I see no objections then |
47 |
21:04:56 <ulm> 2. Approve summary of October meeting |
48 |
21:05:07 <ulm> no summary ready, afaik |
49 |
21:05:17 <ulm> so we can skip this topic |
50 |
21:05:25 <Betelgeuse> anyone want to pickup from tanderson ? |
51 |
21:05:32 <leio> I started work on it, but can't have it ready before tomorrow evening |
52 |
21:05:50 <leio> I can do both previous and this meeting |
53 |
21:05:54 <Betelgeuse> leio: ok good |
54 |
21:05:58 <lu_zero> thank you =) |
55 |
21:05:59 <Calchan> leio, thanks |
56 |
21:06:26 <ulm> leio: thanks |
57 |
21:06:26 --- lu_zero gives voice to zmedico |
58 |
21:06:59 <ulm> lu_zero: right, let's move to 3. Follow-ups from previous meeting |
59 |
21:07:14 <ulm> zmedico: any update on EAPI 3 status? |
60 |
21:08:39 <ulm> anyone else? |
61 |
21:08:49 <lu_zero> zmedico maybe didn't expect us to be this fast |
62 |
21:09:21 <ulm> there's quite some progress in tracker bug 273620 compared to one month ago |
63 |
21:10:09 <lu_zero> 8/20 missing |
64 |
21:10:16 <ulm> yeah |
65 |
21:10:52 <Betelgeuse> the items done are simple and quick |
66 |
21:11:30 <lu_zero> most of the missing ones do not appear this bad as well |
67 |
21:11:34 <ulm> right, but obviously there's progress |
68 |
21:12:11 <ulm> should we move on? |
69 |
21:12:30 <Betelgeuse> I think so |
70 |
21:12:32 <lu_zero> Upgrade paths |
71 |
21:12:34 <Calchan> ulm, yes let's move and maybe get back to this if zac shows up |
72 |
21:12:41 <ulm> Calchan: k |
73 |
21:12:41 <lu_zero> I agree |
74 |
21:13:18 <ulm> leio: "Upgrade path for old systems" |
75 |
21:13:23 <leio> I personally do not think in-tree versions of python certainly need to be EAPI-0 (but have to be EAPI-1), as presumably the system that is getting updated already has a python installed, so just a version of portage that supports newer EAPI (and its direct and indirect dependencies) need to work with EAPI-0, this includes depending on only a python version that used to be EAPI-0 and available for a long time. The main question in my mind |
76 |
21:13:23 <leio> is deciding how far back we want to support things _now_, and go from there to always support back to that point. Some ideas include making periodic portage tree snapshots and whitelisting necessary system packages for distfiles mirrors, so that it is always possible to upgrade step by step through these snapshots. I will follow-up on gentoo-dev for wider discussion with good initial discussion starting write-up soon |
77 |
21:14:18 <leio> how much ago from today we want to support also related to the bash-3.2 question later in the agenda |
78 |
21:14:29 <leio> relates* |
79 |
21:14:31 <Calchan> I think the underlying question in all of this is how long we want to maintain upgrade paths, once we know that it's easy to see what was stable this long ago and if anything was broken then we fix it |
80 |
21:14:53 <Betelgeuse> I would keep main tree in shape for one year. |
81 |
21:15:06 <Betelgeuse> Then if we can provide snapshots and a guide that would be great. |
82 |
21:15:17 <Calchan> I'd definitely agree with that |
83 |
21:15:19 <lu_zero> Betelgeuse how many back snapshot/years ? |
84 |
21:15:20 <Betelgeuse> Would mainly mean someone periodically tries to updgrade form an old snapshot. |
85 |
21:15:28 <DrEeevil> as long as it is "simple" like keeping around only one version of all system packages (or all deps of portage) it has a low enough cost |
86 |
21:15:39 <Betelgeuse> lu_zero: I would say two years. |
87 |
21:15:49 <Betelgeuse> I have seen many times people trying to update around a year marker |
88 |
21:15:56 <Betelgeuse> but beyond two years seems two much work |
89 |
21:16:04 <Betelgeuse> s/two/too/ |
90 |
21:16:22 <dertobi123> we can archive snapshots every - say - three months and it's system packages distfiles |
91 |
21:16:23 <leio> I don't think the cost in keeping support for upgrading from older system is big after we start doing it - users can go step by step, upgrade package manager to 2009 upgrade path snapshot helper, then to 2010, then to 2011, etc |
92 |
21:16:36 <lu_zero> if we just have them incremental (snap0 -> snap1 -> ... -> current stable) |
93 |
21:16:38 <Betelgeuse> If we have a good schedule for testing upgrades it should be quite simple. |
94 |
21:16:50 <lu_zero> won't take more work but just space |
95 |
21:16:52 <leio> only cost there would be distfiles and snapshot mirroring space |
96 |
21:16:55 <Betelgeuse> I think someone just needs to take responsibility and start a project for this. |
97 |
21:17:10 <dertobi123> i wouldn't say "we do this for 2 years" - as long as that's working it might be a benefit for people upgrading from much older boxes |
98 |
21:17:57 <Calchan> dertobi123, as long as the snapshots are being done it's just a matter of disk space on our servers to keep them around |
99 |
21:18:06 <dertobi123> Calchan: exactly, yes |
100 |
21:18:08 <lu_zero> so we agree that we'll keep as many snapshot as possible within our infra/mirror limit or 2 years? |
101 |
21:18:18 <DrEeevil> and that is negligible - system is ~100MB per snapshot |
102 |
21:18:34 <Calchan> so there's no point limiting the storage to 2 years |
103 |
21:18:58 <leio> I'll get a gentoo-dev discussion going in the coming days, summarizing all the current thoughts and ideas |
104 |
21:19:06 <lu_zero> ok |
105 |
21:19:11 * dertobi123 nods |
106 |
21:19:12 <ulm> leio: sounds good |
107 |
21:19:27 <Betelgeuse> leio: Could you start a project page too while at it? |
108 |
21:19:34 <Calchan> lu_zero, let's say we require 2 years of snapshots and that beyond that it's infra's decision to keep what's older |
109 |
21:19:52 <lu_zero> Calchan sounds good |
110 |
21:20:03 * Calchan smells good too |
111 |
21:20:57 <leio> Betelgeuse: maybe after discussion? |
112 |
21:21:02 <Betelgeuse> leio: sure |
113 |
21:21:08 <Betelgeuse> leio: just making sure someone follows up |
114 |
21:21:13 <Betelgeuse> leio: and it's not just discussion and then nothing |
115 |
21:21:15 <leio> Ok, but I'm not confident I can be involved with that project in the longer term |
116 |
21:21:19 <Calchan> isn't there a 3 year retention requirement with the GPL ? we could sync with that too |
117 |
21:21:36 <leio> that requirement applies to for-profits I think |
118 |
21:21:44 <Betelgeuse> leio: sure but if you can't find someone just bring it up that we need someone |
119 |
21:21:45 <leio> err, for non-community-distribution |
120 |
21:21:50 <leio> Betelgeuse: nod |
121 |
21:23:02 <ulm> anything else for this topic? |
122 |
21:23:22 <lu_zero> we could move |
123 |
21:23:32 <ulm> 4. Prefix support in main Portage tree |
124 |
21:23:38 <Calchan> hold on, what's the plan? |
125 |
21:23:41 <leio> Calchan: actually good point, I think the alternative provided by 3c in GPL-2 only covers object code noncommercial distos |
126 |
21:23:49 <leio> distros* |
127 |
21:24:02 <Calchan> leio starts a discussion on -dev and we vote on the outcome of that next time? |
128 |
21:24:21 <Betelgeuse> ulm: I think we should vote on the one year tree requirement |
129 |
21:24:42 <Betelgeuse> to make it explicit |
130 |
21:24:58 <Calchan> Betelgeuse, would that imply reverting any breakage that wouldn't satisfy the one year tree requirement? |
131 |
21:25:11 <Betelgeuse> Calchan: yes |
132 |
21:25:12 --> mpagano (n=mpagano@gentoo/developer/mpagano) has joined #gentoo-council |
133 |
21:25:19 <Calchan> Betelgeuse, ok, thanks for the clarification |
134 |
21:25:40 <Calchan> ulm, so do we vote? |
135 |
21:25:42 <Betelgeuse> I would leave how to handle older than that to the leio started discussion and the resulting proejct |
136 |
21:25:44 <ulm> Betelgeuse: can you word the question we should vote on? |
137 |
21:25:45 <leio> I'd find it more reasonable to vote on this next time then |
138 |
21:26:11 <Betelgeuse> ulm: Ebuild tree should provide upgrade path to a system that hasn't been updated in a year. |
139 |
21:26:29 <ulm> Betelgeuse: leio has a point, there was no vote foreseen on the agenda |
140 |
21:26:50 <Betelgeuse> ulm: You can ask if people are not ready to vote |
141 |
21:26:54 <Calchan> ulm, so what? let's not find lame excuses for not making progress |
142 |
21:27:03 <Betelgeuse> ulm: They can just say not ready |
143 |
21:27:09 <Betelgeuse> ulm: Then we just don't get a majority |
144 |
21:27:19 <ulm> ok, let's give it a try then ;) |
145 |
21:27:20 <leio> the proposed wording sounds good to me for a todays vote too. I'd like some "at least" wording though |
146 |
21:27:24 <Calchan> ulm, great |
147 |
21:27:45 <Calchan> leio, good point |
148 |
21:27:50 * dertobi123 agrees with leio |
149 |
21:28:01 <leio> and s/should/must |
150 |
21:28:23 <ulm> "Ebuild tree must provide upgrade path for at least one year." |
151 |
21:28:26 <Calchan> so does everybody with the wording: "Ebuild tree must provide upgrade path to a system that hasn't been updated in at least one year" |
152 |
21:28:41 <ulm> or that |
153 |
21:28:47 <lu_zero> since the time of the newer snapshot? |
154 |
21:29:12 <ulm> and maybe s/system/stable system/ |
155 |
21:29:15 <leio> this is irregardless of snapshots. Snapshots would provide a way to upgrade from even older systems |
156 |
21:29:16 <lu_zero> since "an year" is a sliding definition |
157 |
21:29:55 --> grobian (n=grobian@gentoo/developer/grobian) has joined #gentoo-council |
158 |
21:29:58 <Calchan> lu_zero, sliding, but that means that I any time you don't need to resort to snapshots if you updated in the past year |
159 |
21:30:02 <leio> "Ebuild tree must provide an upgrade path to a stable system that hasn't been updated for one year" would sound good to me |
160 |
21:30:18 <ulm> ^^ please vote on this |
161 |
21:30:24 <lu_zero> fine for me |
162 |
21:30:28 <ulm> yes from me |
163 |
21:30:29 <dertobi123> ok for me |
164 |
21:30:30 <Betelgeuse> yes |
165 |
21:30:34 <Calchan> agreed, leio's wording is clear enough |
166 |
21:30:38 <Calchan> and I vote yes |
167 |
21:30:46 <leio> my "at least" proposal made it more confusing, sorry :) |
168 |
21:30:48 <leio> I vote yes |
169 |
21:31:06 <ulm> DrEeevil? |
170 |
21:31:30 <DrEeevil> yes |
171 |
21:31:41 <ulm> unanimous then |
172 |
21:31:48 <ulm> let's move on |
173 |
21:31:50 <leio> I propose adding in the summary also this: "The council encourages trying to keep ebuild tree upgrade path support for older system than a year as well" |
174 |
21:32:05 <leio> but not important, this will be discussed in the thread I bet. |
175 |
21:32:16 <Calchan> leio, I would keep that for the thread |
176 |
21:32:24 --- ulm gives voice to grobian |
177 |
21:32:38 <ulm> next topic "4. Prefix support in main Portage tree" |
178 |
21:33:13 <ulm> grobian: can you give an outline of the proposal? |
179 |
21:33:43 <grobian> ehm, well, it's pretty simple |
180 |
21:34:03 <grobian> we propose to simply make a preparation for full prefix support to portage |
181 |
21:34:19 --> reavertm (n=reavertm@×××××××××××××××××××××××××.pl) has joined #gentoo-council |
182 |
21:34:26 <grobian> that means that the variables EPREFIX, ED and EROOT will be initialised to the values '', D and ROOT |
183 |
21:34:51 <Calchan> what are the implications for non-prefix devs? |
184 |
21:34:52 <grobian> this gives the advantage that we don't have to set ED and EROOT in every ebuild we require them |
185 |
21:34:55 <Calchan> and users |
186 |
21:35:23 --> Innocenti (n=Innocent@××××××××××××××××××××××.nl) has joined #gentoo-council |
187 |
21:35:24 <grobian> implications are outlined in my earlier mail to -dev |
188 |
21:35:29 <leio> I'm worried about the implications of this being an EAPI feature in relation to the upgrade path concerns and usage of these variables in eclasses |
189 |
21:36:01 <grobian> leio: can you be more specific? |
190 |
21:36:15 <Calchan> grobian, do you have a link in the archives? I can't seem to find it anymore |
191 |
21:36:17 <leio> eclasses use $D, $ROOT and so on |
192 |
21:36:33 <grobian> leio: yes |
193 |
21:36:45 <ulm> grobian: does it mean we have to substitute all occurences ${D} -> ${ED} and ${ROOT} -> ${EROOT} in ebuilds and eclasses? |
194 |
21:36:52 <leio> the eclasses and ebuilds involved in package manager deptree should remain lower EAPI (EAPI-0 right now) to support upgrading the package manager |
195 |
21:37:07 <grobian> ulm: unfortunately not all of them, that's why we need to make a distinction between the two |
196 |
21:37:29 <grobian> leio: yes, but we can set ED if ED is not set to D, making them compatible in EAPI0 |
197 |
21:37:36 <grobian> (and up) |
198 |
21:37:38 <leio> which means portage EAPI-2+prefix provided variables can't be relied upon (upgrade path stuff going to be discussed on gentoo-dev soon). Maybe the eclasses and ebuilds involved in there can define those themselves then |
199 |
21:38:06 <leio> and for those eclasses and ebuilds that are allowed to upgrade EAPI requirements, it is a convenience |
200 |
21:38:09 <grobian> leio: that's why we proposed using use prefix || local ED=${D} |
201 |
21:38:39 <leio> ok, so something to just communicate very well if this is accepted |
202 |
21:38:46 <grobian> Calchan: I'm searching |
203 |
21:38:52 <Calchan> grobian, thanks |
204 |
21:39:15 <leio> agenda had some link. That one? |
205 |
21:39:44 <grobian> http://article.gmane.org/gmane.linux.gentoo.devel/63527/match=gentoo+prefix+eprefix |
206 |
21:40:20 <ulm> yeah, that's the one in the agenda |
207 |
21:40:26 <ulm> only on gmane |
208 |
21:40:34 <grobian> see that thread for the idea to inject this inter-eapi that will allow to skip to do the conditional ED and EROOT |
209 |
21:40:40 <leio> the details on the need for separate variables slightly still escapes me |
210 |
21:41:11 <grobian> leio: look at the make DESTDIR=${D} install example |
211 |
21:42:16 <Betelgeuse> grobian: Maybe the prefix-vars eclass idea is simpler. It's easier to remove in the future if we have something better. |
212 |
21:42:33 <grobian> leio: if you insert the offset in there, you simply get a double offset, because you supplied it during configure too |
213 |
21:42:33 <Betelgeuse> grobian: If we use an EAPI for uninstall the support stays there for quite a while |
214 |
21:42:38 <grobian> Betelgeuse: it's only not possible |
215 |
21:43:08 <Betelgeuse> grobian: how come? |
216 |
21:43:15 <grobian> Betelgeuse: D and ROOT need not to be set when the ebuild is sourced |
217 |
21:43:33 <leio> grobian: I think I got it. The point was that DESTDIR remains $D and the problem happens if you need to access things post make install |
218 |
21:44:02 <grobian> leio: yes, you want to avoid writing ${EPREFIX} all the time, hence the shorthand ED |
219 |
21:44:56 <leio> would dobin and similar methods automatically get ${EPREFIX} in front for defaults with a new EAPI? |
220 |
21:45:19 <grobian> leio: no, but they would in the Prefix EAPI, as is implemented now |
221 |
21:46:13 <grobian> the EAPI we talk about now is just a mere convenience EAPI that allows to avoid lots of conditional code such that Prefix and gx86 can share the same ebuilds |
222 |
21:46:42 <Calchan> grobian, would that EAPI slot in between EAPI3 and EAPI4? |
223 |
21:46:44 <grobian> it basically all needed |
224 |
21:46:47 <leio> the question was if the default locations would be changed in the new EAPI feature you are proposing to be accepted :) And if insinto and such would add $EPREFIX in front automatically, or all such places need to be updated as well. But this is perhaps getting into too much details for this point of time |
225 |
21:46:51 <Calchan> grobian, or could that be EAPI4? |
226 |
21:46:51 <ulm> grobian: only feature being the new variables? |
227 |
21:46:59 <grobian> leio: nothing changes for gx86 |
228 |
21:47:36 <ulm> Calchan: let's postpone the eapi details, we have an extra topic for it |
229 |
21:47:44 <grobian> Calchan: we need it now, and very fast, otherwise I'll stop waiting and just add lots of conditional code |
230 |
21:47:48 <ulm> s/eapi/eapi numbering/ |
231 |
21:47:50 <leio> but they can't share the same ebuilds if insinto and dobin and so on don't have EPREFIX in front of the arguments |
232 |
21:48:29 <ulm> leio: EPREFIX is empty in main tree |
233 |
21:48:30 <grobian> ulm: a prefix enabled package manager can do offset installs using those variables |
234 |
21:48:30 <leio> ok, they can if your portage branch does add that automatically for these functions |
235 |
21:48:42 <Calchan> grobian, how come you need it fast? I understand the workload issue but I think it's not a reason to take chances with the tre |
236 |
21:49:18 <Calchan> e |
237 |
21:49:30 <grobian> Calchan: because we already started doing that, and then zmedico came with this idea, so we suspended for that, because it sounds good to us |
238 |
21:49:46 <lu_zero> grobian your effort could be merged with the multilib idea we more or less discussed the past council? |
239 |
21:50:11 <grobian> leio: yes, the prefix portage is doing that exactly, meaning that if EPREFIX='', it behaves as normal portage |
240 |
21:50:14 <lu_zero> grobian which would be a confortable timeframe for you? |
241 |
21:50:15 <Calchan> grobian, I think the details of prefix and its implications should be reviewed, and I would want to involve QA in that as they're usually the ones picking up the pieces |
242 |
21:50:22 <grobian> lu_zero: it's completely unrelated IMO |
243 |
21:50:45 <Betelgeuse> grobian: To vote on I would like to have the finished spec for the new EAPI text. |
244 |
21:51:02 <Betelgeuse> When when we have that we should see where we are with EAPI 3. |
245 |
21:51:03 <Calchan> that's the bare minimum |
246 |
21:51:03 <lu_zero> grobian I see |
247 |
21:51:06 <grobian> lu_zero: well, zmedico told me he could do it pretty fast, so that's what I'm counting on |
248 |
21:51:20 <lu_zero> grobian fast as in week but not months |
249 |
21:51:27 <lu_zero> or fast as in yesterday? ^^ |
250 |
21:51:36 <grobian> I can still wait a week |
251 |
21:51:47 <Calchan> what after that? |
252 |
21:51:57 <grobian> then I'll just continue I started on |
253 |
21:52:06 <grobian> s/on/with/ |
254 |
21:52:39 <Calchan> grobian, you may want to hold back making major changes to ebuilds you don't maintain |
255 |
21:52:40 <leio> hopefully getting acks from relevant maintainers... |
256 |
21:52:47 <lu_zero> the request is just a minimal change that will be completely transparent for non-prefix users? |
257 |
21:52:57 <grobian> Calchan: that's why we get maintainers in the loop |
258 |
21:53:07 <grobian> like we wrote in the mail |
259 |
21:53:14 <Betelgeuse> I don't see a problem with going forward with maintainer blessing in the meanwhile. |
260 |
21:53:27 <grobian> lu_zero: yes |
261 |
21:53:30 <Calchan> grobian, is what you started doing reversible? |
262 |
21:53:45 <Betelgeuse> For non prefix users at least. |
263 |
21:53:53 <grobian> Calchan: yes, by basically sedding ED to D |
264 |
21:54:12 <grobian> Betelgeuse: prefix users already have ED and EROOT |
265 |
21:54:13 <leio> basically, but not quite - too short keyword to sed :) |
266 |
21:54:24 <Calchan> grobian, and are you touching any system packages? |
267 |
21:54:28 <lu_zero> ${D} =P |
268 |
21:54:39 <lu_zero> anyway |
269 |
21:54:49 <grobian> Calchan: not yet, but prefix code is already in toolchain*.eclass with ack from spanky |
270 |
21:54:57 <leio> "system packages" is quite relative these days, unfortunately. E.g pam -> pam-base[gnome-keyring] -> gnome-keyring -> ... |
271 |
21:55:37 <ulm> we are already behind schedule |
272 |
21:55:49 <ulm> so how do we go on from here? |
273 |
21:56:02 <ulm> should we vote if council generally supports the idea? |
274 |
21:56:07 <lu_zero> I like the idea of merging prefix with the main portage |
275 |
21:56:08 <Calchan> grobian, I would agree with the move once this has been properly reviewed, but inflicting us a one week deadline is rather unrealistic |
276 |
21:56:39 <grobian> Calchan: we can always benefit from it when it comes later |
277 |
21:56:54 <Calchan> grobian, benefit of what? |
278 |
21:57:08 <grobian> an eapi that we don't need to set ED or EROOT in |
279 |
21:57:31 <Calchan> I think you're pushing the schedules here |
280 |
21:57:47 <Calchan> and again I understant the impact on your workload |
281 |
21:57:54 <grobian> sorry, I feel I just made a simple request |
282 |
21:58:09 <grobian> you could see me coming I guess |
283 |
21:58:15 <Betelgeuse> 7w 30 |
284 |
21:58:20 <ulm> if the only change is definition of three variables there can't be much danger of damaging anything |
285 |
21:59:03 --> NeddySeagoon (n=NeddySea@gentoo/developer/NeddySeagoon) has joined #gentoo-council |
286 |
21:59:08 <grobian> if the position of the portage team is of any value to you, I think you should consult them |
287 |
21:59:20 <Calchan> grobian, I was going to propose that |
288 |
21:59:50 <Calchan> one thing that bothers me is that it affects past EAPIs |
289 |
22:00:03 <grobian> in what way does it do that? |
290 |
22:00:06 <Betelgeuse> Calchan: no? |
291 |
22:00:50 <Calchan> mmhhh... this would prove I didn't understant the whole thing correctly |
292 |
22:01:10 <Calchan> which would mean I'm not ready to vote on this |
293 |
22:01:21 <grobian> Calchan: if EAPI="2+prefix" ; then define ED, EROOT, EPREFIX ; fi |
294 |
22:01:28 <ulm> we are at this topic since 30 min and I propose to move discussion to -dev ml |
295 |
22:01:44 <ulm> since I don't see us converging towards a vote |
296 |
22:01:57 <lu_zero> ulm 4.1 could be voted already |
297 |
22:02:01 <Calchan> grobian, don't eclasses need to be modified? |
298 |
22:02:02 <Betelgeuse> grobian: Couldn't we go with having ROOT and D available on global scope immediately? |
299 |
22:02:31 <grobian> Calchan: eclasses: yes, take KDE eclasses as example |
300 |
22:02:55 <grobian> Betelgeuse: I don't like stacking many things in one, but then I won't mind either |
301 |
22:03:23 <Calchan> grobian, I will but not now, we're running late with the meeting |
302 |
22:03:39 <lu_zero> the main problem is that 1 week is a pretty short time |
303 |
22:03:50 <ulm> let's vote on 4.1 then "Does the council generally support this idea?" |
304 |
22:04:01 <ulm> and say if you're not ready |
305 |
22:04:08 <lu_zero> I like the idea |
306 |
22:04:24 <Calchan> ulm, does that mean the general idea of eventually having prefix in the tree? |
307 |
22:04:38 <ulm> Calchan: that's the implication |
308 |
22:04:40 <leio> I support the intention of getting all this into the main tree, but unsure of the first step proposed right now. |
309 |
22:04:42 <dertobi123> in general i like it and want to see it happen, but as the past about 30 minutes proved - there are lots of things to discuss |
310 |
22:04:58 <Betelgeuse> I support having prefix eventually merged to main tree but I won't vote on EAPis without a written spec. |
311 |
22:05:07 * ulm also supports the idea in general |
312 |
22:05:09 <lu_zero> Betelgeuse that is 4.2 |
313 |
22:05:31 <Betelgeuse> lu_zero: in my opinion ties back to 4.1 |
314 |
22:05:51 <Calchan> I would vote yes |
315 |
22:06:08 <ulm> DrEeevil? |
316 |
22:06:27 <DrEeevil> I support the idea and grobian's plan |
317 |
22:06:34 <DrEeevil> the timeline is debatable |
318 |
22:07:09 <ulm> so we have unanimous support for the general idea, but there's need for additional discussion |
319 |
22:07:23 <ulm> let's postpone 4.2 to next meeting then |
320 |
22:07:28 <lu_zero> ok |
321 |
22:07:41 <DrEeevil> ok |
322 |
22:08:05 <ulm> grobian: you can live with that? |
323 |
22:08:30 <leio> We need a PMS patch, no? |
324 |
22:08:30 <Calchan> grobian, would you start a discussion on that and make sure we get relevant feedback on this, so that we can vote on this next time? |
325 |
22:08:33 <ulm> grobian: and please get the discussion on -dev ml going |
326 |
22:08:43 <grobian> sure I can, but may I request you all to do a little bit of homework for next meeting then? That'll save you some time in here ;) |
327 |
22:09:14 <Calchan> grobian, seriously, your message was posted a bit late for me to research that thouroughly enough |
328 |
22:09:17 <grobian> ulm: all questions have been addressed in the mail as far as I can see, so I would request you to put the questions out there, so I can reiterate |
329 |
22:09:27 <Betelgeuse> Calchan: the original message was on gentoo-dev quite a while ok I think |
330 |
22:09:48 <Calchan> Betelgeuse, a bit short for me, slow and old brain and all that |
331 |
22:09:55 <Calchan> plus life |
332 |
22:09:57 <grobian> 3 weeks, 1 day, 10 hours and 57 minutes ago |
333 |
22:09:58 <Betelgeuse> Calchan: 3 weeks ago |
334 |
22:10:05 <ulm> grobian: o.k., i'll followup on the ml then |
335 |
22:10:08 <Calchan> 3 weeks? ok than, I slacked |
336 |
22:10:12 <ulm> next topic: "5. Usage of bash 3.2 features in Portage tree" |
337 |
22:10:17 <leio> grobian: will you write a PMS patch? |
338 |
22:10:30 <grobian> leio: if you request me to do so, I'm willing to do |
339 |
22:10:52 <Calchan> grobian, please do, if we have all material ready for next time it'll be easier |
340 |
22:11:15 <grobian> Calchan: ok, I'll do |
341 |
22:11:18 <ulm> patrick's message is here: http://archives.gentoo.org/gentoo-council/msg_ed3cba3e0ded55c4e497451af46ea55b.xml |
342 |
22:11:25 <leio> grobian: at some point it will be necessary if the discussion leads to a potential accepting of it, the sooner the better. Things might be clearer for the discussion as well if there's a concrete detailed PMS patch to discuss |
343 |
22:11:25 <Calchan> grobian, thanks |
344 |
22:11:27 <ulm> we've moved on ;) |
345 |
22:11:39 <ulm> stop discussing topic 4 please |
346 |
22:12:03 <Calchan> this issue can easily be answered with the decision we've made in 3.2 |
347 |
22:12:18 <ulm> right, it's linked to that |
348 |
22:12:29 <Calchan> is 3.2 stable for at least a year? |
349 |
22:13:00 <ulm> DrEeevil: can you answer this? |
350 |
22:13:08 <DrEeevil> bash 3.2 has been stable for much more than a year |
351 |
22:13:22 <DrEeevil> bash 3.2 was added Oct 2006 and stabled May 2007 |
352 |
22:13:54 <leio> that part sounds OK. Now the problem is it being part of EAPI-0 and how amending of that is done as a process |
353 |
22:14:30 <Calchan> is it that urgent that we can't wait for EAPI3? |
354 |
22:14:40 <DrEeevil> unrelated to EAPI |
355 |
22:14:41 <Betelgeuse> Calchan: You should know global scope issues |
356 |
22:14:45 <DrEeevil> please stop confusing things :) |
357 |
22:14:47 <Calchan> oh right |
358 |
22:14:49 <Betelgeuse> Calchan: To parse the EAPI out |
359 |
22:14:49 <Calchan> sorry |
360 |
22:15:28 <Betelgeuse> leio: We as a council can decide for EAPI 0. |
361 |
22:15:35 <lu_zero> I think we could safely amend pms |
362 |
22:15:57 <ulm> if we want to be consequent, we should either revert all usage of 3.2 features in the tree, or allow 3.2 in general |
363 |
22:16:03 <DrEeevil> exactly |
364 |
22:16:12 <DrEeevil> reverting will be a very unpleasant thing to do |
365 |
22:16:14 <ulm> probably it's too late for the first option already |
366 |
22:16:35 <dertobi123> given the fact that we have bash 3.2 stable for >2 years i think this mostly is a non-issue. therefore i'd prefer "fixing" pms and requiring bash-3.2 thus allowing it in general |
367 |
22:16:48 <ulm> but we should make sure that this won't happen again for bash 4.0 |
368 |
22:16:51 <Betelgeuse> Let's see for any bash >3.2 features they will be reverted |
369 |
22:16:54 <lu_zero> I'd go with the simpler way |
370 |
22:17:04 <ulm> Betelgeuse: exactly |
371 |
22:17:05 <lu_zero> Betelgeuse agreed |
372 |
22:17:06 <Calchan> is there any chance that we could end up in a situation where we can't parse the ebuild and thus not get the EAPI? |
373 |
22:17:20 <DrEeevil> Calchan: bash4 features potentially |
374 |
22:17:30 <DrEeevil> bash 3.0/3.2 changes are small enough to be parseable |
375 |
22:18:20 <-- dabbott|work has quit (Client Quit) |
376 |
22:18:29 <Calchan> DrEeevil, so why do we care about requiring 3.2 then? |
377 |
22:18:40 <Betelgeuse> Ideally we would have repoman parsing the ebuilds with a 3.2 parser. |
378 |
22:18:45 <DrEeevil> Calchan: because it is actively used |
379 |
22:19:12 <DrEeevil> either we allow it (fix PMS) or we don't (fix tree), but having the spec and the product disagree like that is bad |
380 |
22:19:20 <Calchan> DrEeevil, I would tend to consider that an error if it can't be relied on |
381 |
22:19:33 <DrEeevil> Calchan: an error with >150 occurances in eclasses only |
382 |
22:19:51 <Calchan> DrEeevil, can't be sedded? |
383 |
22:19:58 <DrEeevil> Calchan: no, not that easy |
384 |
22:20:09 <DrEeevil> and people will not appreciate having good features removed |
385 |
22:20:09 <ulm> Calchan: and what would be the point? |
386 |
22:20:35 <Calchan> ulm, teaching people to not use features they can't rely on? |
387 |
22:20:51 <ulm> Calchan: we can do this for bash 4.0 features ;) |
388 |
22:21:00 <dertobi123> ulm: we *should* or better *must* |
389 |
22:21:06 <DrEeevil> Calchan: you're about a year late for that |
390 |
22:21:10 --> Zorry (n=zorry@fu/coder/zorry) has joined #gentoo-council |
391 |
22:21:21 <Calchan> DrEeevil, so what? |
392 |
22:21:22 <DrEeevil> people warned back then and noone seemed to care, so it started to get used more and more |
393 |
22:21:27 <DrEeevil> procedural fail. |
394 |
22:22:02 <ulm> I think all arguments have been said and we can vote: "Should usage of bash 3.2 features in the Portage tree be a) forbidden (i.e. tree reverted to 3.0), b) allowed (i.e. PMS changed), or should c) the issue be ignored?" |
395 |
22:22:17 <DrEeevil> we've been doing (c) for long enough |
396 |
22:22:31 <lu_zero> still is an option |
397 |
22:22:44 <ulm> lu_zero: that's why it's listed |
398 |
22:22:51 <dertobi123> i think c is not an option to vote upon |
399 |
22:23:19 <Calchan> I still don't know what is to be gained by using 3.2, and from what I understand not much if anything |
400 |
22:23:42 <DrEeevil> Calchan: I see it mostly as a matter of having a correct specification |
401 |
22:23:57 <DrEeevil> if PMS is supposed to have any relevance it needs to document reality |
402 |
22:24:08 <dertobi123> reality already is that we have 3.2 features being used and the only thing we can do about this *now* is to change pms to reflect that behaviour but also to make sure such doesn't happen again with bash-4 |
403 |
22:24:10 <Calchan> which doesn't matter if people don't foolow it like they did |
404 |
22:24:26 <DrEeevil> dertobi123: agreed |
405 |
22:25:01 <DrEeevil> Calchan: they weren't, in any way, sanctioned |
406 |
22:25:15 <DrEeevil> hey, why not use the shiny features! |
407 |
22:25:19 <ulm> we may also have a stronger point for forbidding 4.0 features if PMS reflects the real status of the tree |
408 |
22:25:39 <Betelgeuse> If we can make repoman fail people won't add new features |
409 |
22:25:50 <Betelgeuse> I bet much of it is just because people don't know/notice |
410 |
22:26:03 <DrEeevil> the bash 3.2 features were quite conscious |
411 |
22:26:09 <Betelgeuse> DrEeevil: PMS authors can't really upgrade the bash version but the council should |
412 |
22:26:56 <ulm> so vote please: "Should usage of bash 3.2 features in the Portage tree be a) forbidden (i.e. tree reverted to 3.0), or b) allowed (i.e. PMS changed)" |
413 |
22:27:03 <Betelgeuse> b |
414 |
22:27:05 <ulm> i vote for b |
415 |
22:27:07 <Calchan> Betelgeuse, I'd agree with you but it's still not a good enough reason to let people not respect a decision previously made by the council |
416 |
22:27:11 <DrEeevil> b |
417 |
22:27:15 <lu_zero> b |
418 |
22:27:20 <Calchan> a |
419 |
22:27:26 <dertobi123> b |
420 |
22:27:32 <leio> b |
421 |
22:27:38 <tanderson> I'd like to request some general consensus that we shouldn't repeat things like this however |
422 |
22:27:54 <tanderson> So people can't introduce 4.0 features and then say "PMS should reflect reality!" |
423 |
22:27:56 <ulm> I count 1a 6b |
424 |
22:28:10 <ulm> tanderson: that was my next point |
425 |
22:28:15 <Betelgeuse> ulm: Vote on >3.2 features will be reverted please |
426 |
22:28:24 <ulm> Betelgeuse: yep |
427 |
22:28:55 <tanderson> ulm: great, I would likely quit if people tried that one. :p |
428 |
22:29:02 <Betelgeuse> Calchan: Yes but being able to use 3.2 features is useful |
429 |
22:29:08 <ulm> "Should features of >=bash-4 be disallowed and reverted in the tree?" |
430 |
22:29:09 <lu_zero> I'm ok with reverting as well |
431 |
22:29:32 <Calchan> why not >3.2, just in case |
432 |
22:29:35 <Betelgeuse> Calchan: The only way of getting there without this that I know of is glep 55... |
433 |
22:30:03 <ulm> Calchan: hm, 3.2_p39 > 3.2 |
434 |
22:30:12 <ulm> give me a proper version spec ;) |
435 |
22:30:12 <leio> or the many counter proposals of glep 55, but lets not go there |
436 |
22:30:16 <Calchan> Betelgeuse, agreed, but I still have a problem with people not respecting rules |
437 |
22:31:31 <Betelgeuse> Calchan: Nothing in our docs really teaches what's 3.2 |
438 |
22:31:31 <lu_zero> Calchan rules must be clear |
439 |
22:31:41 <Betelgeuse> Calchan: We don't teach new recruits either |
440 |
22:31:41 <Betelgeuse> Calchan: I will add a new question based on these votes |
441 |
22:32:30 <DrEeevil> Calchan: if there is no enforcement (even after repeatedly pointing out the issue) then there's no motivation to respect the rules |
442 |
22:32:30 <Betelgeuse> ulm: Ebuilds must be parseable with =bash-3.2* |
443 |
22:32:43 <ulm> Betelgeuse: perfect :) |
444 |
22:33:24 <leio> global scope or all of it? |
445 |
22:33:34 <ulm> all of it |
446 |
22:33:37 <Betelgeuse> leio: all of it |
447 |
22:33:37 <DrEeevil> all of it |
448 |
22:33:38 <leio> (global scope DEPEND could >bash-4) |
449 |
22:33:48 <leio> ok, just to be clear :) |
450 |
22:33:50 <ulm> so please vote on: "Ebuilds must be completely parseable with =bash-3.2*, any use of later bash features will be reverted." |
451 |
22:33:58 <Betelgeuse> yes |
452 |
22:34:01 <ulm> yes |
453 |
22:34:05 <dertobi123> yes |
454 |
22:34:18 <DrEeevil> yes |
455 |
22:34:23 <leio> yes |
456 |
22:34:25 <lu_zero> yes |
457 |
22:34:49 <ulm> Calchan? |
458 |
22:34:58 <tanderson> DrEeevil: rules don't get removed simply because noone obeys them |
459 |
22:35:15 <DrEeevil> tanderson: that's how democracy usually works |
460 |
22:35:29 <Calchan> DrEeevil, no that's anarchy |
461 |
22:35:36 <Calchan> ulm, sorry I lost internet for a while |
462 |
22:35:54 <Betelgeuse> DrEeevil: In democracy you take the changes to the people in charge who change the rules |
463 |
22:35:55 <Calchan> I'm ok with the wording although I voted against that |
464 |
22:36:08 <DrEeevil> civil disobedience |
465 |
22:36:12 <lu_zero> well |
466 |
22:36:14 <ulm> o.k, so 6 yes, 1 no |
467 |
22:36:17 <DrEeevil> the rosa parks kind of thing |
468 |
22:36:26 <Betelgeuse> DrEeevil: is not needed if the system works |
469 |
22:36:27 <lu_zero> people in charge listen to the other people usually |
470 |
22:36:42 <leio> Someone please find out at some point what developer helping features bash-4 would provide to see if we should start thinking of ways how to allow it properly without breaking anything (yes, I realize this will involve glep55 or alternatives, it's for prioritizing work on such a solution or not) |
471 |
22:36:49 <tanderson> DrEeevil: and you don't see civil disobedience before going to authority do you? |
472 |
22:37:06 <DrEeevil> tanderson: you try to ignore the discussions on the mailinglist about a year ago |
473 |
22:37:08 <Betelgeuse> Calchan: You had a timebox? |
474 |
22:37:08 <Calchan> you guys can finish this discussion next time you meet at the pub |
475 |
22:37:18 <lu_zero> now... |
476 |
22:37:20 <Betelgeuse> Any way we are pass 90 mins |
477 |
22:37:23 <DrEeevil> tanderson: it was discussed and ignored |
478 |
22:37:23 <ulm> we're over time |
479 |
22:37:25 <Calchan> Betelgeuse, no, just crappy internet at work |
480 |
22:37:38 <ulm> can we still discuss topic 6? |
481 |
22:37:49 <ulm> or should we postpone it? |
482 |
22:38:06 <Betelgeuse> We can but I will need to go visit neighbourghs shortly |
483 |
22:38:17 <Betelgeuse> I will be back in 10 mins |
484 |
22:38:28 <dertobi123> postpone. |
485 |
22:38:31 <lu_zero> I'd rather postpone |
486 |
22:39:13 <Calchan> can we make sure we keep the discussion on this alive so that next time all we need to do is vote? |
487 |
22:39:19 <ulm> Calchan: sure |
488 |
22:39:35 <Calchan> we should do that more in general by the way |
489 |
22:39:45 <ulm> so let's postpone topic 6 "Preservation of file modification times in EAPI 3 " |
490 |
22:39:52 <Calchan> council metings are not a good time for technical discussions |
491 |
22:39:56 <ulm> right |
492 |
22:40:13 <ulm> any other business? |
493 |
22:40:24 <leio> When is the next meeting |
494 |
22:40:26 <dertobi123> next meeting. when? who's taking care of the agenda? |
495 |
22:40:27 <ulm> who will take chair for the next meeting? |
496 |
22:40:39 <Calchan> I can if nobody wants |
497 |
22:40:55 <dertobi123> what about december 7th? that's in 4 weeks |
498 |
22:41:17 <ulm> general question is if we shall keep the 4 weeks interval |
499 |
22:41:32 <ulm> we originally said third monday in month |
500 |
22:41:48 <Calchan> we may need to start thinking of christmas time, not everybody may be available 4 weeks after dec 7 |
501 |
22:42:09 <leio> that is 4th January |
502 |
22:42:22 <dertobi123> we can do december 7th and something mid-january |
503 |
22:42:36 <Calchan> leio, which proves again that I can't count to 4... ;) |
504 |
22:43:16 <ulm> so let's note december 7th 19 UTC, calchan prepares agenda and takes the chair |
505 |
22:43:23 <Calchan> jan 4th is ok with me although I'll just be flying back from japan after 2 weeks without internet |
506 |
22:43:35 <Calchan> ulm, ok |
507 |
22:43:59 <ulm> leio: you followup on the upgrade path thingy? |
508 |
22:43:59 <lu_zero> Calchan you'll be in tokyo? |
509 |
22:44:12 <leio> ulm: yes |
510 |
22:44:14 <Calchan> lu_zero, 1h north of tokyo |
511 |
22:44:21 <ulm> so, open floor |
512 |
22:44:23 --- ulm sets mode -m #gentoo-council |
513 |
22:44:55 <lu_zero> Calchan make sure if you could attend the tlug event if you hadn't already ^^; |
514 |
22:45:15 --- ulm removes voice from DrEeevil grobian |
515 |
22:45:26 <Calchan> lu_zero, when/where? not sure I can make it though |
516 |
22:46:11 <leio> fyi, reavertm said bash-4 would mostly provide associative arrays (array indexes with strings instead of just numeric indeces), which is probably not very important to have for ebuild/eclasses |
517 |
22:46:18 <leio> ulm: you get to kick me if I don't do so ;) |
518 |
22:46:42 <ulm> leio: will do |
519 |
22:46:54 <ciaranm> bash 4 has a tr replacement builtin, which is handy. but since it's only handy for global scope things... |
520 |
22:47:59 <ulm> one more thing, can somebody get the automatic council reminders going again? |
521 |
22:48:23 <ulm> there used to be a ml posting (by vapier I think) two weeks in advance |
522 |
22:48:25 <leio> maybe someone could contact vapier and ask to tweak the cron script |
523 |
22:48:38 <leio> it's still happening, just with wrong dates at wrong times |
524 |
22:50:05 <Betelgeuse> hard to cron when the dates are not solid |
525 |
22:50:23 <Betelgeuse> the one who does the agenda should schedule reminders and send them |
526 |
22:50:35 <ulm> or that |
527 |
22:50:43 <ulm> but I forgot last time |
528 |
22:51:09 <Betelgeuse> Calchan: please add a note to your calendar |
529 |
22:51:27 <ulm> anyway, seems there are no pressing topics for open floor |
530 |
22:51:39 <ulm> so let's call it end of meeting |
531 |
22:51:46 <ulm> thanks everybody |
532 |
22:52:03 <Calchan> Betelgeuse, thanks ;o) |