1 |
ulm 14/08/26 20:33:03 |
2 |
|
3 |
Added: 20140826.txt |
4 |
Log: |
5 |
Log for 20140826 meeting. |
6 |
|
7 |
Revision Changes Path |
8 |
1.1 xml/htdocs/proj/en/council/meeting-logs/20140826.txt |
9 |
|
10 |
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20140826.txt?rev=1.1&view=markup |
11 |
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20140826.txt?rev=1.1&content-type=text/plain |
12 |
|
13 |
Index: 20140826.txt |
14 |
=================================================================== |
15 |
<ulm> 19:00, so let's start the meeting [21:00] |
16 |
<ulm> agenda is here: http://article.gmane.org/gmane.linux.gentoo.project/4014 |
17 |
<ulm> roll call |
18 |
<radhermit> here |
19 |
<rich0> here |
20 |
<dilfridge> here |
21 |
<WilliamH> here |
22 |
<blueness> here |
23 |
<ulm> dberkholz? [21:01] |
24 |
<ulm> anyone has donnie's number? [21:02] |
25 |
<blueness> lets start |
26 |
<radhermit> he sent it to the list |
27 |
<radhermit> or alias |
28 |
<dilfridge> sent him a text... [21:03] |
29 |
<blueness> dilfridge, were you going to compile a list? |
30 |
<blueness> :) |
31 |
<dilfridge> yes, soon... |
32 |
<ulm> anyway, let's start |
33 |
<ulm> first topic: dynamic dependencies in portage |
34 |
<ulm> http://thread.gmane.org/gmane.linux.gentoo.project/3943 |
35 |
<dilfridge> wheeee [21:04] |
36 |
<ulm> any opinions? |
37 |
<dilfridge> two things from me... |
38 |
<rich0> So, I believe the portage team indicated that they plan to remove |
39 |
dynamic deps the way they are now, but to come up with another |
40 |
solution to the rebuild problem. |
41 |
<rich0> As long as the latter accompanies the former when it goes mainstream, |
42 |
I don't have a problem with it. [21:05] |
43 |
<dilfridge> 1) some eclasses add dependencies which need to be changed every |
44 |
now and then... e.g. minimal perl version in perl-module.eclass, |
45 |
or minimal qt version for kde ebuilds |
46 |
<ulm> I'd say this is up to the portage team. they had added the feature, so |
47 |
they can change or remove it as well |
48 |
<dilfridge> noone's come up with a real solution for this yet, except for a |
49 |
true mass rebuild |
50 |
<WilliamH> There is a solution that mgorny came up with, a new @changed-deps |
51 |
set that would rebuild everything. [21:06] |
52 |
<WilliamH> with new dependencies |
53 |
<dilfridge> yes... wanna rebuild all perl-related ebuilds in your system? :) |
54 |
<ulm> WilliamH: IIUC this has the same problem as dynamic dependencies |
55 |
<ulm> if the ebuild is gone, the package won't be rebuilt [21:07] |
56 |
<blueness> i haven't seen a solution that satisfies my so i'm not sure what we |
57 |
are resolving here. i'd say ask the portage team to come up with |
58 |
something. |
59 |
<ulm> so it would bite users who haven't upgraded for a long time |
60 |
<dilfridge> 2) that said, I dont intend to fully block this move by the |
61 |
portage team, but before it's actually disabled fully, we need a |
62 |
working, reliable alternative and a good idea for the needed |
63 |
workflow and tree policies. |
64 |
<blueness> ulm, the ebuild is still in vardb |
65 |
<radhermit> as a pkgcore guy, I've never been pro-dynamic deps due a number of |
66 |
issues most of which have been raised in the various threads |
67 |
<rich0> dilfridge: ++ |
68 |
<ulm> blueness: the one with the old dependencies [21:08] |
69 |
<blueness> ah |
70 |
<blueness> yes |
71 |
<radhermit> imo, we should really spec out a vdb format |
72 |
<rich0> That is my concern. I'm fine with one step back and two steps |
73 |
forward, but we can't do the latter without plans to do the former. |
74 |
<rich0> Err, the other way around :) |
75 |
<blueness> radhermit, take a look at https://wiki.gentoo.org/wiki/GLEP:64 |
76 |
<rich0> Sure, to some extent the portage team should take the lead on this, |
77 |
but this affects the whole tree and how it is maintained. |
78 |
<ulm> so, should we ask the portage team to outline their solution, before |
79 |
they remove the current feature? [21:09] |
80 |
<dilfridge> this does not so much affect the maintainer of a single package, |
81 |
<radhermit> blueness: ah gotcha |
82 |
<dilfridge> but much more the people maintaining virtuals and eclasses... |
83 |
<Arfrever> There is no consensus in Portage team to remove dynamic |
84 |
dependencies. |
85 |
<WilliamH> Arfrever: I thought there was. [21:10] |
86 |
<dilfridge> Sorry can you type louder, I didn't hear you... |
87 |
<radhermit> anyway, I also agree that the support shouldn't just be yanked out |
88 |
of portage since it's been the default for a long time |
89 |
<radhermit> and devs have become implicitly used to its mostly hidden workings |
90 |
[21:11] |
91 |
<dilfridge> exactly. |
92 |
<rich0> I think a long-term plan would alleviate a lot of concerns. It isn't |
93 |
enough to say dynamic deps are broken. We need to talk about what the |
94 |
better solution actually is. I'm sure it will be supported then. |
95 |
<ulm> Arfrever: the portage team meeting summary posted on 2014-07-25 says |
96 |
that dynamic dependencies will be turned off |
97 |
<dilfridge> right now the bigger surprise is that sometimes dynamic deps dont |
98 |
work... |
99 |
<ulm> that's the most official statement we have |
100 |
<ulm> so we should go from there [21:12] |
101 |
<ulm> anyone wants to come up with a motion? [21:13] |
102 |
<WilliamH> I'm thinking that if they are turned off by default that will be ok |
103 |
as long as we can turn them on until a fix is developed. |
104 |
<WilliamH> We won't know what is broken by them being turned off until they |
105 |
are turned off... [21:15] |
106 |
<Arfrever> ulm: This "meeting" was even not announced before it (mailing lists |
107 |
were down). I have received e-mail about announcement of meeting |
108 |
after meeting. Probably very small number of members of team |
109 |
participated in meeting. |
110 |
<WilliamH> Arfrever: you should be able to check that by the meeting log if it |
111 |
is posted. [21:16] |
112 |
<ulm> How about this: "The council asks the portage team to outline their |
113 |
long-term plan regarding removal or replacement of dynamic dependencies, |
114 |
before they actually remove this feature." |
115 |
<dilfridge> ulm: that plus: |
116 |
<blueness> yes |
117 |
<dilfridge> "Especially tree policies and the handling of eclasses and |
118 |
virtuals need to be clarified." [21:17] |
119 |
<Arfrever> (Anyway I am one of Portage team members, who would vote for |
120 |
keeping dynamic dependencies.) |
121 |
<ulm> good |
122 |
<rich0> wfm |
123 |
<ulm> "The council asks the portage team to first outline their long-term plan |
124 |
regarding removal or replacement of dynamic dependencies, before they |
125 |
remove this feature. Especially tree policies and the handling of |
126 |
eclasses and virtuals need to be clarified." |
127 |
<blueness> dilfridge, "especially" -> "In particular" (very minor change but |
128 |
sounds better) |
129 |
<ulm> Please vote |
130 |
* dilfridge yes |
131 |
<blueness> yes |
132 |
<radhermit> yes |
133 |
<rich0> yes [21:18] |
134 |
<ulm> ok, with blueness's change of wording |
135 |
<ulm> yes |
136 |
<blueness> yes |
137 |
<WilliamH> yes |
138 |
<radhermit> sure |
139 |
<ulm> unanimous, for the council members present |
140 |
<ulm> anything else for this topic? |
141 |
<dilfridge> just the remark [21:19] |
142 |
<dilfridge> that this is much more critical for slow arches as e.g. arm or ppc |
143 |
where the rebuilds are more time-consuming. |
144 |
<ulm> do you want this in the summary? |
145 |
* dilfridge pulls up the obligatory remark about a "beowulf cluster of |
146 |
those"... [21:20] |
147 |
<dilfridge> nah, log is enough :) |
148 |
<ulm> next topic: additional features for EAPI 6 |
149 |
<ulm> http://thread.gmane.org/gmane.linux.gentoo.project/4002 |
150 |
<ulm> mgorny asks us to reopen the list of features [21:21] |
151 |
<Arfrever> ulm: (It was never closed anyway...) |
152 |
<radhermit> were they closed? I didn't think so yet |
153 |
<ulm> k |
154 |
<ulm> I suggest we discuss features individually [21:22] |
155 |
<dilfridge> + |
156 |
<ulm> 1. passing additional configure options, namely --docdir and --htmldir |
157 |
<ulm> I would be in favour of this |
158 |
<radhermit> imo, should be fine |
159 |
* dilfridge abstains |
160 |
<ulm> looks pretty safe |
161 |
<WilliamH> should be ok [21:23] |
162 |
<ulm> and mgorny has done a tree-wide scan IIUC |
163 |
<ulm> so let's just vote |
164 |
* ulm yes |
165 |
<radhermit> yes |
166 |
* dilfridge abstain |
167 |
<blueness> yes |
168 |
* rich0 yes |
169 |
* WilliamH yes |
170 |
<ulm> passes with 5 yes 1 abstention 1 absent [21:24] |
171 |
<ulm> 2. additional default suffixes for dohtml |
172 |
<ulm> IMHO changing the default is pointless |
173 |
<WilliamH> What are the requested suffixes? [21:25] |
174 |
<ulm> it's just a default, and there are options -a and -A to change the list |
175 |
of suffixes |
176 |
<ulm> .xml .xhtml .ico .svg |
177 |
<ulm> bug 423245 |
178 |
<willikins> ulm: https://bugs.gentoo.org/423245 "[Future EAPI] dohtml: Extend |
179 |
default list of extensions"; Gentoo Hosted Projects, PMS/EAPI; |
180 |
UNCO; arfrever.fta:pms-bugs |
181 |
<ulm> I have some ideas about moving the dohtml function from the PM to an |
182 |
eclass [21:26] |
183 |
<blueness> this is minor, imo. its harmless to change the default but there's |
184 |
no strong reason to do so. |
185 |
<ulm> blueness: well, devs have to learn the difference between EAPIs then |
186 |
[21:27] |
187 |
<dilfridge> right. let's keep it as it is. |
188 |
<blueness> ulm, yeah i guess |
189 |
<ulm> and you'd have to check the set of installed files for every EAPI bump |
190 |
from 5 to 6 |
191 |
<ulm> more discussion? |
192 |
<ulm> seems not, so let's vote [21:28] |
193 |
* ulm no |
194 |
* dilfridge no |
195 |
<blueness> no |
196 |
<rich0> no |
197 |
* WilliamH abstains |
198 |
<radhermit> no |
199 |
<ulm> rejected, 5 no 1 abstention 1 absent |
200 |
<ulm> 3. build-time switching variant of || () [21:29] |
201 |
<ulm> bug 489458 |
202 |
<willikins> ulm: https://bugs.gentoo.org/489458 "[Future EAPI] Replace || with |
203 |
something less ambiguous"; Gentoo Hosted Projects, PMS/EAPI; CONF; |
204 |
ciaran.mccreesh:pms-bugs |
205 |
<ulm> I would be very much in favour of this feature if there was proof of |
206 |
concept ready |
207 |
<rich0> I think mgorny's proposal seemed reasonable enough. |
208 |
<dilfridge> well, right now we're only saying what things people should work |
209 |
on... this is not the final decision on EAPI features (since that |
210 |
needs the implementation) [21:30] |
211 |
<rich0> ulm: well, that seems to be the point of pre-voting on EAPIs |
212 |
<blueness> rich0, you mean comment #14? |
213 |
<rich0> blueness: yes |
214 |
<ulm> we could provisionally approve it, with the condition that it will only |
215 |
be included in EAPI 6 if an implementation is ready |
216 |
<dilfridge> comment 14 is the one to go for, yes |
217 |
<rich0> We'll have to re-vote on the final PMS once there is a reference |
218 |
implemenation. [21:31] |
219 |
<dilfridge> ulm: isn't that true for everything right now? |
220 |
<rich0> dilfridge: yes |
221 |
<rich0> PMS policy is that we don't put stuff in until implemented in portage |
222 |
<rich0> This is basically to help devs avoid wasting time on stuff only to |
223 |
have it yanked back out |
224 |
<rich0> I think it makes sense to do it this way. |
225 |
<ulm> dilfridge: mgorny has implemented everything else in his branch of |
226 |
portage already |
227 |
<rich0> People can still work on stuff we vote no on, or not work on stuff we |
228 |
vote yes on. It just gives them a sense of where we stand. |
229 |
[21:32] |
230 |
<dilfridge> right... but that wasn't the case at the time of the first votes |
231 |
:P |
232 |
<ulm> o.k. |
233 |
* radhermit will need to look at pkgcore code a bit, but it seems ok-ish |
234 |
<blueness> rich0, i agree that this resolves one ambiguity, but to be honest, |
235 |
i can't fully get my head around all the possibilities here, and |
236 |
i'm not sure mgorny's solution really nails everything |
237 |
<ulm> so please vote on provisional approvement, with the condition that it |
238 |
will only be included if an implementation is ready |
239 |
* ulm yes |
240 |
* dilfridge yes [21:33] |
241 |
<blueness> yes |
242 |
<rich0> yes |
243 |
<radhermit> yes |
244 |
<ulm> WilliamH? |
245 |
<rich0> blueness: agree that when you get into nesting the actual use gets |
246 |
murky. However, I think that the rules are straightforward enough. I |
247 |
guess if you get ||= embedded in || you have to decide if the ||= |
248 |
propagates through. |
249 |
* WilliamH yes [21:34] |
250 |
<ulm> rich0: these things are what makes the implementation difficult ;) |
251 |
<radhermit> it will probably need some more forceful or better defined |
252 |
boundaries though, I'm assuming that'll happen if it gets into PMS |
253 |
<ulm> passes unanimously (1 absent) |
254 |
<ulm> we're perfectly in time :) [21:35] |
255 |
<ulm> next: open bugs |
256 |
<ulm> bug 424647 |
257 |
<willikins> ulm: https://bugs.gentoo.org/424647 "archives.gentoo.org: Broken |
258 |
URLs for e.g. gentoo-dev-announce and others"; Gentoo |
259 |
Infrastructure, Other; CONF; darkside:infra-bugs |
260 |
<dilfridge> I think infra has bigger problems atm... [21:36] |
261 |
<ulm> yeah |
262 |
<ulm> no progress there |
263 |
<rich0> agree, but how is this a council issue anyway? |
264 |
<ulm> and no action by council |
265 |
<rich0> we basically look at this every month and say, yes, it is a problem |
266 |
<blueness> heh yeah [21:37] |
267 |
<rich0> Either somebody volunteers to fix it, or maybe we beg the trustees to |
268 |
pay somebody to fix it for us |
269 |
<ulm> we could remove council from cc |
270 |
<blueness> let's do that |
271 |
<ulm> and forget about the problem |
272 |
<rich0> I don't think we're adding any value |
273 |
<dilfridge> which problem? [21:38] |
274 |
<rich0> :) |
275 |
<blueness> dilfridge, the broken archives |
276 |
<ulm> dilfridge: that we have no archives |
277 |
<blueness> email archives |
278 |
<dilfridge> ... :) |
279 |
<radhermit> pretty sure he was joking |
280 |
<ulm> any objections against removing us from cc? |
281 |
<dilfridge> no objections. [21:39] |
282 |
<rich0> We should use discourse. :) |
283 |
<blueness> ulm, i agree, remove us |
284 |
<ulm> next, bug 477030 |
285 |
<willikins> https://bugs.gentoo.org/477030 "Missing summary for 20130611 |
286 |
council meeting"; Doc Other, Project-specific documentation; CONF; |
287 |
ulm:council |
288 |
<ulm> I became impatient and wrote a summary :) [21:40] |
289 |
<ulm> http://www.gentoo.org/proj/en/council/meeting-logs/20130611-summary.txt |
290 |
<ulm> asking for approval here |
291 |
<blueness> ulm, were you at the meeting? |
292 |
<ulm> you should also have received the draft by e-mail |
293 |
<ulm> blueness: yes |
294 |
<blueness> okay then, do it [21:41] |
295 |
<radhermit> looks fine, imo |
296 |
<ulm> I don't see any objections [21:42] |
297 |
<rich0> I say go ahead |
298 |
<ulm> so I'll add the link to the council page |
299 |
<blueness> well i have not basis to disagree since i wasn't there |
300 |
<ulm> finally, bug 503382 |
301 |
<willikins> https://bugs.gentoo.org/503382 "Missing summaries for 20131210, |
302 |
20140114, and 20140225 council meetings"; Doc Other, |
303 |
Project-specific documentation; CONF; ulm:council |
304 |
<ulm> but donnie is not here :( [21:43] |
305 |
<ulm> so again no progress, I fear |
306 |
<ulm> hm, there's another bug actually [21:44] |
307 |
<ulm> bug 520074 |
308 |
<willikins> ulm: https://bugs.gentoo.org/520074 "GLEP 39 rump council |
309 |
privilege escalation in secret meeting"; Doc Other, GLEP Changes; |
310 |
UNCO; wking:glep |
311 |
<ulm> rich0: you've participated in the discussion there, so do you want to |
312 |
comment? [21:45] |
313 |
<rich0> I think it is much ado about nothing. |
314 |
<rich0> :) |
315 |
<ulm> yeah, that's my impression too |
316 |
* WilliamH agrees |
317 |
<ulm> from a theoretical pov he might have a point [21:46] |
318 |
<rich0> Certainly our rules aren't airtight, but we only lead because |
319 |
everybody recognizes that we lead. |
320 |
<blueness> actually, i had a secret meeting yesterday and voted to disband the |
321 |
council, so this is now mute |
322 |
<ulm> but I doubt that it has any practical relevance |
323 |
<blueness> moot |
324 |
<dilfridge> yes... it's very much about codifying common sense, which is |
325 |
something you can spend all eternity on |
326 |
<rich0> If we say something that 99% of devs disagree with, they'll just |
327 |
ignore us. |
328 |
<blueness> shoudl we have a quorum for other reasons? |
329 |
<rich0> Well, we already disband the council anytime half of us don't show up. |
330 |
[21:47] |
331 |
<rich0> So, that seems to be overkill already. :) |
332 |
<WilliamH> Right. |
333 |
<blueness> yeah |
334 |
<rich0> I don't care for the slacker rule at all, but that is a separate |
335 |
matter. |
336 |
<ulm> any action? |
337 |
<ulm> remove council from cc? |
338 |
<blueness> yeah |
339 |
<dilfridge> rich0: I would not mind adding that the council with <=50% |
340 |
attendance can't decide anything, but if that requires an eternal |
341 |
discussion on how to add something, I dont care. |
342 |
<rich0> I don't object either, but then you get into the whole argument about |
343 |
who is allowed to edit GLEP 39 [21:48] |
344 |
<dilfridge> exactly. |
345 |
<ulm> dilfridge: it was handled that way when it occured |
346 |
* radhermit doesn't care that much, seems people have replied enough on the |
347 |
bug |
348 |
<ulm> only once, in 2008 |
349 |
<dilfridge> yes. |
350 |
<rich0> I don't have an issue with just fixing it, but maybe the same folks |
351 |
who like the slacker rule might object. :) |
352 |
<ulm> ok, I'll remove us from cc [21:49] |
353 |
<ulm> next, open floor |
354 |
<ulm> and we're still in time :) [21:50] |
355 |
<dilfridge> meh |
356 |
<dilfridge> right. |
357 |
<dilfridge> [21:47:28] <_AxS_> done! |
358 |
<dilfridge> official commendation to _AxS_ for revbumping all dev-perl to |
359 |
EAPI=5 :) |
360 |
<rich0> woot! |
361 |
<ulm> great :) |
362 |
* WilliamH agrees, that is good news |
363 |
<blueness> that was a lot of work [21:51] |
364 |
<WilliamH> That obosoletes perl-cleaner right? |
365 |
<blueness> so am i to understand this correctly that we won't need |
366 |
perl-cleaner anymore |
367 |
<dilfridge> not yet |
368 |
<WilliamH> obsoletes * |
369 |
<ulm> let's finish EAPI 6 so the perl team won't be put out of work :p |
370 |
<dilfridge> WilliamH: there are some ebuilds left (not many), more complex |
371 |
apps that also install perl modules [21:52] |
372 |
<blueness> dilfridge, what will perl-cleaner be needed for? |
373 |
<blueness> i see |
374 |
<dilfridge> once these are gone too, we'll ban EAPI<5 in perl-module.eclass |
375 |
<dilfridge> then it's obsolete. |
376 |
<blueness> what about perl virtuals? |
377 |
<dilfridge> well, the new ones are also marked EAPI=5 [21:53] |
378 |
<dilfridge> but there's no hurry there |
379 |
<dilfridge> no eclass, nothing to rebuild |
380 |
<blueness> i see |
381 |
<dilfridge> (and the EAPI makes no difference) |
382 |
<ulm> anything else for open floor? [21:54] |
383 |
<ulm> seems not to be the case [21:55] |
384 |
<ulm> next meeting will be on 2014-09-09 |
385 |
<ulm> so I'll send the call for agenda items today [21:56] |
386 |
*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council: |
387 |
"Next meeting: Tuesday, 9 Sep 2014 19:00 UTC | |
388 |
http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 | |
389 |
http://wiki.gentoo.org/wiki/Project:Council" |