ulm 14/08/26 20:33:03 Added: 20140826.txt Log: Log for 20140826 meeting.
Revision Changes Path 1.1 xml/htdocs/proj/en/council/meeting-logs/20140826.txt file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20140826.txt?rev=1.1&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20140826.txt?rev=1.1&content-type=text/plain Index: 20140826.txt =================================================================== <ulm> 19:00, so let's start the meeting [21:00] <ulm> agenda is here: http://article.gmane.org/gmane.linux.gentoo.project/4014 <ulm> roll call <radhermit> here <rich0> here <dilfridge> here <WilliamH> here <blueness> here <ulm> dberkholz? [21:01] <ulm> anyone has donnie's number? [21:02] <blueness> lets start <radhermit> he sent it to the list <radhermit> or alias <dilfridge> sent him a text... [21:03] <blueness> dilfridge, were you going to compile a list? <blueness> :) <dilfridge> yes, soon... <ulm> anyway, let's start <ulm> first topic: dynamic dependencies in portage <ulm> http://thread.gmane.org/gmane.linux.gentoo.project/3943 <dilfridge> wheeee [21:04] <ulm> any opinions? <dilfridge> two things from me... <rich0> So, I believe the portage team indicated that they plan to remove dynamic deps the way they are now, but to come up with another solution to the rebuild problem. <rich0> As long as the latter accompanies the former when it goes mainstream, I don't have a problem with it. [21:05] <dilfridge> 1) some eclasses add dependencies which need to be changed every now and then... e.g. minimal perl version in perl-module.eclass, or minimal qt version for kde ebuilds <ulm> I'd say this is up to the portage team. they had added the feature, so they can change or remove it as well <dilfridge> noone's come up with a real solution for this yet, except for a true mass rebuild <WilliamH> There is a solution that mgorny came up with, a new @changed-deps set that would rebuild everything. [21:06] <WilliamH> with new dependencies <dilfridge> yes... wanna rebuild all perl-related ebuilds in your system? :) <ulm> WilliamH: IIUC this has the same problem as dynamic dependencies <ulm> if the ebuild is gone, the package won't be rebuilt [21:07] <blueness> i haven't seen a solution that satisfies my so i'm not sure what we are resolving here. i'd say ask the portage team to come up with something. <ulm> so it would bite users who haven't upgraded for a long time <dilfridge> 2) that said, I dont intend to fully block this move by the portage team, but before it's actually disabled fully, we need a working, reliable alternative and a good idea for the needed workflow and tree policies. <blueness> ulm, the ebuild is still in vardb <radhermit> as a pkgcore guy, I've never been pro-dynamic deps due a number of issues most of which have been raised in the various threads <rich0> dilfridge: ++ <ulm> blueness: the one with the old dependencies [21:08] <blueness> ah <blueness> yes <radhermit> imo, we should really spec out a vdb format <rich0> That is my concern. I'm fine with one step back and two steps forward, but we can't do the latter without plans to do the former. <rich0> Err, the other way around :) <blueness> radhermit, take a look at https://wiki.gentoo.org/wiki/GLEP:64 <rich0> Sure, to some extent the portage team should take the lead on this, but this affects the whole tree and how it is maintained. <ulm> so, should we ask the portage team to outline their solution, before they remove the current feature? [21:09] <dilfridge> this does not so much affect the maintainer of a single package, <radhermit> blueness: ah gotcha <dilfridge> but much more the people maintaining virtuals and eclasses... <Arfrever> There is no consensus in Portage team to remove dynamic dependencies. <WilliamH> Arfrever: I thought there was. [21:10] <dilfridge> Sorry can you type louder, I didn't hear you... <radhermit> anyway, I also agree that the support shouldn't just be yanked out of portage since it's been the default for a long time <radhermit> and devs have become implicitly used to its mostly hidden workings [21:11] <dilfridge> exactly. <rich0> I think a long-term plan would alleviate a lot of concerns. It isn't enough to say dynamic deps are broken. We need to talk about what the better solution actually is. I'm sure it will be supported then. <ulm> Arfrever: the portage team meeting summary posted on 2014-07-25 says that dynamic dependencies will be turned off <dilfridge> right now the bigger surprise is that sometimes dynamic deps dont work... <ulm> that's the most official statement we have <ulm> so we should go from there [21:12] <ulm> anyone wants to come up with a motion? [21:13] <WilliamH> I'm thinking that if they are turned off by default that will be ok as long as we can turn them on until a fix is developed. <WilliamH> We won't know what is broken by them being turned off until they are turned off... [21:15] <Arfrever> ulm: This "meeting" was even not announced before it (mailing lists were down). I have received e-mail about announcement of meeting after meeting. Probably very small number of members of team participated in meeting. <WilliamH> Arfrever: you should be able to check that by the meeting log if it is posted. [21:16] <ulm> How about this: "The council asks the portage team to outline their long-term plan regarding removal or replacement of dynamic dependencies, before they actually remove this feature." <dilfridge> ulm: that plus: <blueness> yes <dilfridge> "Especially tree policies and the handling of eclasses and virtuals need to be clarified." [21:17] <Arfrever> (Anyway I am one of Portage team members, who would vote for keeping dynamic dependencies.) <ulm> good <rich0> wfm <ulm> "The council asks the portage team to first outline their long-term plan regarding removal or replacement of dynamic dependencies, before they remove this feature. Especially tree policies and the handling of eclasses and virtuals need to be clarified." <blueness> dilfridge, "especially" -> "In particular" (very minor change but sounds better) <ulm> Please vote * dilfridge yes <blueness> yes <radhermit> yes <rich0> yes [21:18] <ulm> ok, with blueness's change of wording <ulm> yes <blueness> yes <WilliamH> yes <radhermit> sure <ulm> unanimous, for the council members present <ulm> anything else for this topic? <dilfridge> just the remark [21:19] <dilfridge> that this is much more critical for slow arches as e.g. arm or ppc where the rebuilds are more time-consuming. <ulm> do you want this in the summary? * dilfridge pulls up the obligatory remark about a "beowulf cluster of those"... [21:20] <dilfridge> nah, log is enough :) <ulm> next topic: additional features for EAPI 6 <ulm> http://thread.gmane.org/gmane.linux.gentoo.project/4002 <ulm> mgorny asks us to reopen the list of features [21:21] <Arfrever> ulm: (It was never closed anyway...) <radhermit> were they closed? I didn't think so yet <ulm> k <ulm> I suggest we discuss features individually [21:22] <dilfridge> + <ulm> 1. passing additional configure options, namely --docdir and --htmldir <ulm> I would be in favour of this <radhermit> imo, should be fine * dilfridge abstains <ulm> looks pretty safe <WilliamH> should be ok [21:23] <ulm> and mgorny has done a tree-wide scan IIUC <ulm> so let's just vote * ulm yes <radhermit> yes * dilfridge abstain <blueness> yes * rich0 yes * WilliamH yes <ulm> passes with 5 yes 1 abstention 1 absent [21:24] <ulm> 2. additional default suffixes for dohtml <ulm> IMHO changing the default is pointless <WilliamH> What are the requested suffixes? [21:25] <ulm> it's just a default, and there are options -a and -A to change the list of suffixes <ulm> .xml .xhtml .ico .svg <ulm> bug 423245 <willikins> ulm: https://bugs.gentoo.org/423245 "[Future EAPI] dohtml: Extend default list of extensions"; Gentoo Hosted Projects, PMS/EAPI; UNCO; arfrever.fta:pms-bugs <ulm> I have some ideas about moving the dohtml function from the PM to an eclass [21:26] <blueness> this is minor, imo. its harmless to change the default but there's no strong reason to do so. <ulm> blueness: well, devs have to learn the difference between EAPIs then [21:27] <dilfridge> right. let's keep it as it is. <blueness> ulm, yeah i guess <ulm> and you'd have to check the set of installed files for every EAPI bump from 5 to 6 <ulm> more discussion? <ulm> seems not, so let's vote [21:28] * ulm no * dilfridge no <blueness> no <rich0> no * WilliamH abstains <radhermit> no <ulm> rejected, 5 no 1 abstention 1 absent <ulm> 3. build-time switching variant of || () [21:29] <ulm> bug 489458 <willikins> ulm: https://bugs.gentoo.org/489458 "[Future EAPI] Replace || with something less ambiguous"; Gentoo Hosted Projects, PMS/EAPI; CONF; ciaran.mccreesh:pms-bugs <ulm> I would be very much in favour of this feature if there was proof of concept ready <rich0> I think mgorny's proposal seemed reasonable enough. <dilfridge> well, right now we're only saying what things people should work on... this is not the final decision on EAPI features (since that needs the implementation) [21:30] <rich0> ulm: well, that seems to be the point of pre-voting on EAPIs <blueness> rich0, you mean comment #14? <rich0> blueness: yes <ulm> we could provisionally approve it, with the condition that it will only be included in EAPI 6 if an implementation is ready <dilfridge> comment 14 is the one to go for, yes <rich0> We'll have to re-vote on the final PMS once there is a reference implemenation. [21:31] <dilfridge> ulm: isn't that true for everything right now? <rich0> dilfridge: yes <rich0> PMS policy is that we don't put stuff in until implemented in portage <rich0> This is basically to help devs avoid wasting time on stuff only to have it yanked back out <rich0> I think it makes sense to do it this way. <ulm> dilfridge: mgorny has implemented everything else in his branch of portage already <rich0> People can still work on stuff we vote no on, or not work on stuff we vote yes on. It just gives them a sense of where we stand. [21:32] <dilfridge> right... but that wasn't the case at the time of the first votes :P <ulm> o.k. * radhermit will need to look at pkgcore code a bit, but it seems ok-ish <blueness> rich0, i agree that this resolves one ambiguity, but to be honest, i can't fully get my head around all the possibilities here, and i'm not sure mgorny's solution really nails everything <ulm> so please vote on provisional approvement, with the condition that it will only be included if an implementation is ready * ulm yes * dilfridge yes [21:33] <blueness> yes <rich0> yes <radhermit> yes <ulm> WilliamH? <rich0> blueness: agree that when you get into nesting the actual use gets murky. However, I think that the rules are straightforward enough. I guess if you get ||= embedded in || you have to decide if the ||= propagates through. * WilliamH yes [21:34] <ulm> rich0: these things are what makes the implementation difficult ;) <radhermit> it will probably need some more forceful or better defined boundaries though, I'm assuming that'll happen if it gets into PMS <ulm> passes unanimously (1 absent) <ulm> we're perfectly in time :) [21:35] <ulm> next: open bugs <ulm> bug 424647 <willikins> ulm: https://bugs.gentoo.org/424647 "archives.gentoo.org: Broken URLs for e.g. gentoo-dev-announce and others"; Gentoo Infrastructure, Other; CONF; darkside:infra-bugs <dilfridge> I think infra has bigger problems atm... [21:36] <ulm> yeah <ulm> no progress there <rich0> agree, but how is this a council issue anyway? <ulm> and no action by council <rich0> we basically look at this every month and say, yes, it is a problem <blueness> heh yeah [21:37] <rich0> Either somebody volunteers to fix it, or maybe we beg the trustees to pay somebody to fix it for us <ulm> we could remove council from cc <blueness> let's do that <ulm> and forget about the problem <rich0> I don't think we're adding any value <dilfridge> which problem? [21:38] <rich0> :) <blueness> dilfridge, the broken archives <ulm> dilfridge: that we have no archives <blueness> email archives <dilfridge> ... :) <radhermit> pretty sure he was joking <ulm> any objections against removing us from cc? <dilfridge> no objections. [21:39] <rich0> We should use discourse. :) <blueness> ulm, i agree, remove us <ulm> next, bug 477030 <willikins> https://bugs.gentoo.org/477030 "Missing summary for 20130611 council meeting"; Doc Other, Project-specific documentation; CONF; ulm:council <ulm> I became impatient and wrote a summary :) [21:40] <ulm> http://www.gentoo.org/proj/en/council/meeting-logs/20130611-summary.txt <ulm> asking for approval here <blueness> ulm, were you at the meeting? <ulm> you should also have received the draft by e-mail <ulm> blueness: yes <blueness> okay then, do it [21:41] <radhermit> looks fine, imo <ulm> I don't see any objections [21:42] <rich0> I say go ahead <ulm> so I'll add the link to the council page <blueness> well i have not basis to disagree since i wasn't there <ulm> finally, bug 503382 <willikins> https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council <ulm> but donnie is not here :( [21:43] <ulm> so again no progress, I fear <ulm> hm, there's another bug actually [21:44] <ulm> bug 520074 <willikins> ulm: https://bugs.gentoo.org/520074 "GLEP 39 rump council privilege escalation in secret meeting"; Doc Other, GLEP Changes; UNCO; wking:glep <ulm> rich0: you've participated in the discussion there, so do you want to comment? [21:45] <rich0> I think it is much ado about nothing. <rich0> :) <ulm> yeah, that's my impression too * WilliamH agrees <ulm> from a theoretical pov he might have a point [21:46] <rich0> Certainly our rules aren't airtight, but we only lead because everybody recognizes that we lead. <blueness> actually, i had a secret meeting yesterday and voted to disband the council, so this is now mute <ulm> but I doubt that it has any practical relevance <blueness> moot <dilfridge> yes... it's very much about codifying common sense, which is something you can spend all eternity on <rich0> If we say something that 99% of devs disagree with, they'll just ignore us. <blueness> shoudl we have a quorum for other reasons? <rich0> Well, we already disband the council anytime half of us don't show up. [21:47] <rich0> So, that seems to be overkill already. :) <WilliamH> Right. <blueness> yeah <rich0> I don't care for the slacker rule at all, but that is a separate matter. <ulm> any action? <ulm> remove council from cc? <blueness> yeah <dilfridge> rich0: I would not mind adding that the council with <=50% attendance can't decide anything, but if that requires an eternal discussion on how to add something, I dont care. <rich0> I don't object either, but then you get into the whole argument about who is allowed to edit GLEP 39 [21:48] <dilfridge> exactly. <ulm> dilfridge: it was handled that way when it occured * radhermit doesn't care that much, seems people have replied enough on the bug <ulm> only once, in 2008 <dilfridge> yes. <rich0> I don't have an issue with just fixing it, but maybe the same folks who like the slacker rule might object. :) <ulm> ok, I'll remove us from cc [21:49] <ulm> next, open floor <ulm> and we're still in time :) [21:50] <dilfridge> meh <dilfridge> right. <dilfridge> [21:47:28] <_AxS_> done! <dilfridge> official commendation to _AxS_ for revbumping all dev-perl to EAPI=5 :) <rich0> woot! <ulm> great :) * WilliamH agrees, that is good news <blueness> that was a lot of work [21:51] <WilliamH> That obosoletes perl-cleaner right? <blueness> so am i to understand this correctly that we won't need perl-cleaner anymore <dilfridge> not yet <WilliamH> obsoletes * <ulm> let's finish EAPI 6 so the perl team won't be put out of work :p <dilfridge> WilliamH: there are some ebuilds left (not many), more complex apps that also install perl modules [21:52] <blueness> dilfridge, what will perl-cleaner be needed for? <blueness> i see <dilfridge> once these are gone too, we'll ban EAPI<5 in perl-module.eclass <dilfridge> then it's obsolete. <blueness> what about perl virtuals? <dilfridge> well, the new ones are also marked EAPI=5 [21:53] <dilfridge> but there's no hurry there <dilfridge> no eclass, nothing to rebuild <blueness> i see <dilfridge> (and the EAPI makes no difference) <ulm> anything else for open floor? [21:54] <ulm> seems not to be the case [21:55] <ulm> next meeting will be on 2014-09-09 <ulm> so I'll send the call for agenda items today [21:56] *** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council: "Next meeting: Tuesday, 9 Sep 2014 19:00 UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 | http://wiki.gentoo.org/wiki/Project:Council";
