Mar 11 14:59:01 ping dberkholz dilfridge rich0 scarabeus ulm williamh Mar 11 14:59:06 dberkholz dberkholz|mob dilfridge dilfridge|mobile dleverton_ DrEeevil Mar 11 14:59:13 dberkholz|mob, mob? Mar 11 14:59:28 * ulm here Mar 11 14:59:30 mobile Mar 11 14:59:38 ah Mar 11 14:59:44 * rich0 here Mar 11 14:59:47 * dilfridge here Mar 11 14:59:58 he's ganging up on us Mar 11 15:00:13 ping scarabeus ulm williamh Mar 11 15:00:50 * ulm still here ;) Mar 11 15:01:07 scarabeus, WilliamH are missing Mar 11 15:01:47 let's wait a few minutes (the time it takes me to run downstairs and get tea) Mar 11 15:02:25 Sounds good Mar 11 15:02:29 * WilliamH is here Mar 11 15:03:30 scarabeus, ping last time Mar 11 15:03:45 let's start Mar 11 15:03:55 I think we might actually make it through the agenda this time! Mar 11 15:03:56 agenda: http://dev.gentoo.org/~blueness/council/council_agenda_20140311.txt Mar 11 15:04:17 If there are no objections we'll proceed to item 1 Mar 11 15:04:29 Vote: GPG signing GLEP 63 Mar 11 15:04:36 https://wiki.gentoo.org/wiki/GLEP:63 Mar 11 15:05:03 there was discussion whether we should place in the GLEP only the bare specs or also the howto parts Mar 11 15:05:04 So we're voting to accept GLEP 63 which should be ready Mar 11 15:05:22 https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:1001a Mar 11 15:05:32 ^ this is a re-arranged "barebones" version. Mar 11 15:05:48 I'm fine with accepting it as-is as long as it is understood that it isn't effective/implemented until communications/docs/etc are in place. Works fine as a reference for design/etc of all that. Mar 11 15:06:05 I prefer the longer version. Mar 11 15:06:09 Of course, if they do clean up the docs, presumably the docs section of the GLEP should be updated. Mar 11 15:06:18 Just wanted to have something to show up. Mar 11 15:06:37 But it isn't absolutely required if the intent is to just show the state at the time of review. Mar 11 15:07:03 I think the documentation should better go to a less rigid part of the wiki Mar 11 15:07:16 dilfridge, by the longer version you mean the one at https://wiki.gentoo.org/wiki/GLEP:63 Mar 11 15:07:21 so it can be updated more easily, without us voting on it every time Mar 11 15:07:24 blueness: yes. Mar 11 15:07:28 The biggest issue with docs in a GLEP is that they tend to get crufty. Mar 11 15:07:33 Prefer longer with examples, not necessarily as canonical doc Mar 11 15:08:18 I'm fine either way - I could see the argument for either approach. Mar 11 15:08:29 _robbat2|irssi: a penny for your thoughts? Mar 11 15:08:29 Well what came forward last time was to vote on the longer version, so i'm not sure what to do with the shorter one now Mar 11 15:09:16 blueness: the vote is on the longer version... Mar 11 15:09:32 the shorter version is not so much shorter, btw Mar 11 15:10:03 Should be proceed with the vote then? Mar 11 15:10:08 * dilfridge is fine with voting on the long version. Mar 11 15:10:08 on the longer version? Mar 11 15:10:18 wfm Mar 11 15:10:22 wfm too Mar 11 15:10:23 waiting Mar 11 15:11:00 I'm also not sure that the official howto for this should be part of the glep... Mar 11 15:11:05 I'd like to hear robbat2's opinion Mar 11 15:11:37 I'm for longer as I said. Should be clear it's example how to do it now Mar 11 15:12:00 Not docs council must always approve updates of Mar 11 15:12:03 its unlikely things will change Mar 11 15:12:05 I view the docs in the GLEP a bit like a "reference implementation" - it doesn't mean it is the version you run. Mar 11 15:12:17 Granted, they fall considerably short of a reference implementation. Mar 11 15:12:30 <_robbat2|irssi> sorry, was in this talk Mar 11 15:12:39 * kallamej has quit (Ping timeout: 264 seconds) Mar 11 15:12:53 <_robbat2|irssi> and this conference wifi is bad Mar 11 15:13:16 _robbat2|irssi, did you get the backlog? Mar 11 15:13:21 <_robbat2|irssi> i do like the 1001a part Mar 11 15:13:30 <_robbat2|irssi> but i think I need to reformat the recommendation chunk Mar 11 15:13:34 <_robbat2|irssi> to explain what it's doing Mar 11 15:13:38 <_robbat2|irssi> or rather specify Mar 11 15:13:42 <_robbat2|irssi> not in a gnupg config file format Mar 11 15:14:20 <_robbat2|irssi> then after that, explain why Mar 11 15:14:25 <_robbat2|irssi> lastly, in a NEW document Mar 11 15:14:28 <_robbat2|irssi> have the gpg config file Mar 11 15:14:32 <_robbat2|irssi> along with instructions Mar 11 15:14:53 <_robbat2|irssi> is the council in favour of the actual spec contents? Mar 11 15:14:58 <_robbat2|irssi> (aside from the format) Mar 11 15:15:02 In effect, the "bare minimum requirements" are the real policy. The rest is just howtos, commentary on best practices, etc. Mar 11 15:15:14 Only the minimum requirements really have any kind of force. Mar 11 15:15:37 suggestion: we vote now that the minimum requirements remain unchanged Mar 11 15:16:00 <_robbat2|irssi> i'm wondering if some of the parts in recommendations might be moved to the min requirements Mar 11 15:16:06 ok Mar 11 15:16:18 its sounds like you two want to work on this more Mar 11 15:16:23 we can table the vote Mar 11 15:16:44 * WilliamH agrees with blueness Mar 11 15:16:56 works for me too, shall we target the next meeting then? Mar 11 15:17:12 we could have a vote per e-mail if we don't want to delay it by another month Mar 11 15:17:13 dilfridge, yes, we need to vote to table it though (following roberts rules) Mar 11 15:17:39 ulm, i'm not sure there's an urgency, but i'm not against an email vote Mar 11 15:18:10 Those working on implementation shouldn't hold up or anything. Nobody objects to the policy itself. This is really about the docs/etc. Mar 11 15:18:11 _robbat2|irssi: your call (I think in general there is agreement with the specs, but we can't formally vote on something unfinished :) Mar 11 15:18:30 We've been fine on the specs for two months now. Mar 11 15:18:55 rich0, we wanted to see final language, which is why this keeps getting tabled Mar 11 15:19:29 blueness: sure - wasn't a complaint. Just supporting the comment that getting this GLEP approved shouldn't stop anybody from writing infra code, docs, etc. Mar 11 15:19:38 I dont see much disagreement with the specs here... Mar 11 15:20:54 dilfridge, is the short document sufficient for a vote now, given that we agree with the specs? ie are all the spec in there? Mar 11 15:21:41 in my opinion yes, but robbat2 is the real author. Mar 11 15:22:00 _robbat2|irssi, ^^^ any opinion on my question Mar 11 15:22:19 my intention was to have the long and short version "identical in specifications, differing in explanation/docs" Mar 11 15:22:51 i think robbat2 is having net issues Mar 11 15:23:34 i suggest tabling this with a email vote, initiated by dilfridge when he and robbat2 have sorted it out Mar 11 15:23:47 That's fine with me. Mar 11 15:24:11 ok Mar 11 15:24:29 table it? dberkholz rich0 ulm Mar 11 15:24:38 +1 Mar 11 15:24:40 ++ Mar 11 15:24:43 +1 Mar 11 15:24:44 table it Mar 11 15:25:08 okay, dilfridge when you're ready, email the group and we'll vote. otherwise its on the next agenda Mar 11 15:25:14 will do Mar 11 15:25:24 okay next item: Ban on EAPI 1 and 2 should extend to updating EAPI in existing ebuilds Mar 11 15:25:43 ulm, you brought this up, do you want to speak to it? Mar 11 15:26:15 IMHO a "ban" means that once the count of e.g. EAPI 1 ebuilds is down to zero, it should stay there Mar 11 15:26:37 which isn't the case if changing ebuilds to EAPI 1 and 2 is still allowed Mar 11 15:27:03 in other words, these EAPIs are on their way out of the tree Mar 11 15:27:26 ulm, to be honest, i thought that was implicit in what we voted on last time, but i can see how that confusion might arrise because we did say the bans was on "new" ebuilds Mar 11 15:27:29 so there should be no excuse for adding such ebuilds, or changing others to these EAPIs Mar 11 15:28:04 blueness: devs are more creative in interpreting the rules than we had imagined ;) Mar 11 15:28:17 ulm, okay Mar 11 15:28:23 ulm: how are we supposed to add slot deps to EAPI=0 ebuilds then? Mar 11 15:28:29 Why would you change an ebuild *to* one of these eapis? Mar 11 15:28:37 mgorny: update to EAPI 3 or later Mar 11 15:28:59 this goes outside of 'acceptable' for touching sb's package Mar 11 15:29:14 and this is a lot of unnecessary work for old ebuilds Mar 11 15:29:18 but you have to change the EAPI anyway, so why not to a supported one? Mar 11 15:29:37 because changing 0 -> 1 doesn't require many changes, while 0 -> 3 does Mar 11 15:29:41 EAPI 0->1 is less work than 0->5 - less phase rewriting/etc. Mar 11 15:29:48 i see Mar 11 15:29:55 mgorny, just do it one step at a time Mar 11 15:29:55 I can see why people would rather do it. Mar 11 15:29:57 file a bug to maintainer (get ignored) Mar 11 15:30:11 * kallamej (~kallamej@gentoo/developer/kallamej) has joined #gentoo-council Mar 11 15:30:42 does anyone have a count of how many ebuilds we're talking here? Mar 11 15:30:53 less than 300 Mar 11 15:30:57 for eapi 1 Mar 11 15:31:20 If we just made the policy no moving from a non-banned EAPI to a banned one that covers the obvious loophole. Mar 11 15:31:21 EAPI=0 is somewhere around 6000 Mar 11 15:31:45 dilfridge: yeah, but not all of them to be converted to 1 Mar 11 15:31:47 EAPI0 might get an exception. Mar 11 15:31:59 EAPI0 is almost banned, but we have some details to work out first. Mar 11 15:32:06 so the argument here is that any forward ports to 0 must move forward to at least 3 Mar 11 15:32:11 errr. *from 0 Mar 11 15:32:19 I don't see EAPI0->1 as really anything but an improvement. Mar 11 15:32:46 we want to remove EAPI=1 usage, if we allow upgrade 0->1 that will never happen Mar 11 15:32:58 we could add an exception for updating from 0 to 1 in case of slot dependenies Mar 11 15:33:15 dilfridge: at the moment EAPI1 doesn't cost us anything, and EAPI0 will not be around forever. Mar 11 15:33:18 ugh no, that's messy Mar 11 15:33:27 blueness: it is ;) Mar 11 15:33:37 * ulm prefers clear rules Mar 11 15:34:05 The thing is, we have to bite the EAPI3 bullet sooner or later. Mar 11 15:34:36 basically, all the ebuilds that are moved from 0 to 1 now have to be touched a second time lateron Mar 11 15:34:42 To me banned is banned. no emore ebuilds should be committed to the tree with a banned eapi. Mar 11 15:34:52 ulm: they will be mostly removed later on Mar 11 15:35:00 rich0, that's why i'm saying we can move at a comfortable pace here Mar 11 15:35:08 mgorny: honestly, I doubt this Mar 11 15:35:09 we need to fix deps in old versions, they don't take more maint than that Mar 11 15:35:33 at least the ebuilds i was touching had newer versions with newer EAPI Mar 11 15:35:43 If the package manager teams were screaming for EAPI relief I could see pushing harder. Right now they're content. Mar 11 15:35:53 mgorny: if there's a newer ebuild around for the same pkg, you can take that one as example Mar 11 15:36:11 is it really that much work to bring them forward to 3? Mar 11 15:36:25 most of the stuff you can skip, a tiny bit of function refactoring for 2, eh Mar 11 15:36:53 dberkholz, i wouldn't have thought it was that much work, but i guess i can see some thorny situations Mar 11 15:37:12 eapi0 made for some very strange phase coding Mar 11 15:37:17 dberkholz: certainly more opportunity for trouble with the refactoring. Not that big a deal, but if I had to edit 50 ebuilds I'd be reluctant to deal with it... Mar 11 15:37:25 like configuring during compile etc Mar 11 15:37:27 when i have like 50 packages to update, i don't want to waste time converting old ebuilds nobody will use... Mar 11 15:37:48 mgorny, can you give us a deprecation pathway then Mar 11 15:37:58 * alexxy has quit (Ping timeout: 240 seconds) Mar 11 15:37:58 if you tell me it's fine to leave broken deps in old ebuilds, i'm fine with that Mar 11 15:38:10 like if we make an exception for a few older ebuild versions until phased out? Mar 11 15:38:15 Maybe look at it another way - which is worse, treecleaning or having more EAPI1 ebuilds? I think in practice users would object more to the treecleaning. Mar 11 15:38:41 mgorny: if nobody's gonna use them, why not remove them Mar 11 15:39:06 dberkholz: That's the whole ain't-broke-don't-fix thing. Mar 11 15:39:07 * WilliamH agrees with dberkholz here. if no one is using the old stuff, remove it. Mar 11 15:39:24 I'm sure most of it will get treecleaned, but there is some value in delaying that as much as possible. Mar 11 15:39:25 because the maintainer believes in keeping old versions and i'm really tired of fighting all the personal preference issues in gentoo? Mar 11 15:39:40 file a bug for the maintainer? Mar 11 15:39:48 If it IS maintained then LART the maintainer. Mar 11 15:39:49 * alexxy (~alexxy@gentoo/developer/alexxy) has joined #gentoo-council Mar 11 15:40:04 LART? Mar 11 15:40:11 is that like LARP Mar 11 15:40:18 I think the bigger issue is stuff that isn't maintained, in which case the preferences that matter are those of the folks who actually want to do something about it. Mar 11 15:40:34 * Arfrever has quit (Read error: Operation timed out) Mar 11 15:40:45 "Luser Attitude Readjustment Tool" Mar 11 15:40:49 ahah! Mar 11 15:40:54 i like that Mar 11 15:41:11 if the opinion is that it causes to many inconveniences to devs, then our decision on banning EAPIs 1 and 2 was premature and we should revert it Mar 11 15:41:32 which I'd really dislike though Mar 11 15:41:38 sound logic Mar 11 15:42:13 * WilliamH agrees with what was said above. Mar 11 15:42:25 At some point we are going to have to convert all of this stuff to at least eapi 3. Mar 11 15:42:36 inconvenience to devs isn't just a short term thing Mar 11 15:42:43 it's also about long term maintenance inconvenience Mar 11 15:42:57 I don't think we need absolutes. Mar 11 15:43:03 dberkholz, what do you mean? Mar 11 15:43:07 We don't want people writing new stuff in EAPI1/2 Mar 11 15:43:12 having a big stack of EAPIs sitting around is confusing Mar 11 15:43:28 pretty much nobody even remembers what's in what anymore, unless they were around for generation 0 Mar 11 15:43:28 That doesn't mean that using it as a stepping-stone for existing EAPI0 stuff is bad. Mar 11 15:43:49 well, in my opinion there's no real issue here Mar 11 15:44:09 if people are intentionally doing step-0-to-1 to use banned EAPI, there will be action required Mar 11 15:44:14 * WilliamH still thinks that if an eapi is banned it is banned Mar 11 15:44:21 I'm all for banning EAPI0 as well, just with an exception for the toolchain. Mar 11 15:44:39 mgorny: ++ Mar 11 15:44:40 rich0, one at a time! Mar 11 15:45:06 okay has everyone had enough discussion? Mar 11 15:45:11 We're not robots. We don't need rules that a robot can follow, or a lawyer for that matter. Mar 11 15:45:13 but if there's a bug that needs being fixed quickly and with little effort, i don't see doing temporarily EAPI change a problem Mar 11 15:45:42 mgorny: it's also about EAPI support in eclasses Mar 11 15:45:44 mgorny, how would you phrase that as a clean exception to the eapi1/2 ban Mar 11 15:46:07 so we clearly exclude undesireable 0->1 bumps Mar 11 15:46:28 Why not this, EAPI1/2 may not be used for ebuilds that are not already in the tree as of this date. Mar 11 15:46:51 rich0: this would allow 5->1 Mar 11 15:47:03 heh Mar 11 15:47:29 i think rich0 was right about this point, we shouldn't need to explicitly preclude every absurd behavior Mar 11 15:47:30 EAPI1/2 may not be used for ebuilds unless they are already in the tree using EAPI0 as of this date. Mar 11 15:47:43 blueness: if you really feel we need this, how about saying something about timeframe for keeping ebuilds? Mar 11 15:47:59 as in, allowing bump from 0 to 1 when ebuild is not intended to be kept more than 30/60 days or so Mar 11 15:47:59 the thing is, either we trust devs to DTRT, then we don't need a ban Mar 11 15:48:04 mgorny, i like rich0's wording Mar 11 15:48:11 or we don't, then we should enforce it in some way Mar 11 15:48:40 Or more refined, EAPI1/2 may not be used for ebuilds unless they are already in the tree using EAPI0/1/2 as of this date. Mar 11 15:49:05 how do people feel about rich0's extention to the ban on 1/2 ? Mar 11 15:49:05 is there a good reason for using EAPI=2? Mar 11 15:49:05 rich0: better ;) Mar 11 15:49:17 mgorny: If stabilization of EAPI 1 ebuild takes place it can keep it around for longer; to be more clear, the second stabilization of a non-EAPI 1 ebuild after that can block the EAPI 1 ebuild and keep it in position. Mar 11 15:49:27 I mean, the step from 2 to 3 is minima. Mar 11 15:49:43 good point Mar 11 15:49:53 dilfridge: /EAPI/s/2/3/ ? Mar 11 15:50:00 That is really just the minimum policy. Devs should move to EAPI5 whenever practical. Mar 11 15:50:05 (Just hoping the actual cleaning effort and the effect of stabilization is taken into consideration if you really want to see this go towards 0.) Mar 11 15:50:05 And implement slot op deps as well. Mar 11 15:50:44 and use : whenever no other slot is applicable but this is yet another topic Mar 11 15:51:21 "In case of non-maintainer commits to fix dependencies, EAPI=0 ebuilds may be updated to EAPI=1 to keep the changes at a non-intrusive level, as a temporary workaround." Mar 11 15:52:15 sounds good to me, is the committee comfortable with discuss/voting on dilfridge's formulation of the exception? Mar 11 15:52:22 dilfridge: plus the wording from the agenda? Mar 11 15:52:35 why not Mar 11 15:52:36 yes Mar 11 15:52:38 wfm - that's the tightest possible exception - there is a risk that other exceptions will come up. Mar 11 15:52:40 i don't think we need to add specific policy to say something is allowed that our current vote already says is allowed Mar 11 15:52:53 "EAPI 1 and 2 are now banned. This ban should not only be limited to new ebuilds, but should be extended to include updating EAPIs in *existing* ebuilds." Mar 11 15:53:13 plus dilfridge's suggestion above Mar 11 15:53:19 ulm: ++ for now Mar 11 15:53:27 We can revisit if something comes up. Mar 11 15:53:36 this feels like we're getting too specific Mar 11 15:53:40 Seriously, we need to get to the whitespace ban before we run out of time! :) Mar 11 15:53:44 lol Mar 11 15:53:52 okay the motion is: "EAPI 1 and 2 are now banned. This ban should not only be limited to new ebuilds, but should be extended to include updating EAPIs in *existing* ebuilds. In case of non-maintainer commits to fix dependencies, EAPI=0 ebuilds may be updated to EAPI=1 to keep the changes at a non-intrusive level, as a temporary workaround." Mar 11 15:54:17 * ulm yes Mar 11 15:54:20 * rich0 yes Mar 11 15:54:25 * dilfridge yes Mar 11 15:54:26 * blueness yes Mar 11 15:54:28 no, way too specific Mar 11 15:54:41 WilliamH, ??? Mar 11 15:54:56 what does temporary even mean, does that guarantee someone's going to come back and fix it Mar 11 15:54:59 * WilliamH is reading Mar 11 15:55:22 temporary = not eternal Mar 11 15:55:24 dberkholz: in this context it's more or less a declaration of intent... Mar 11 15:55:47 this is about the most restricted exception that I could come up with Mar 11 15:55:52 I don't have a problem with the specificity - this isn't the last meeting of the council ever and we can deal with issues that arise Mar 11 15:55:55 dberkholz: if there are no EAPI 0 ebuilds left, the workaround will end Mar 11 15:56:04 even without WilliamH vote, it passes Mar 11 15:56:19 or if the sun expands to a red giant, if that will happen earlier ;) Mar 11 15:56:31 Dalek invasion. Mar 11 15:56:47 we need to move on to the other issues Mar 11 15:56:51 i'd just define that a banned EAPI means that no new ebuilds or backports are allowed, and in-place edits are discouraged Mar 11 15:56:58 but then again i'm not the chair =) Mar 11 15:57:15 dberkholz, chairs don't drive discussions ;) Mar 11 15:57:50 driving discussions isn't always a bad thing... :) Mar 11 15:58:01 blueness: by robert's rule, you have to admit us to the floor ;) Mar 11 15:58:08 yes Mar 11 15:58:22 its just hard in irc because of timing Mar 11 15:58:30 * dilfridge never got to know that robert Mar 11 15:58:38 lol Mar 11 15:58:48 are we done with this issue? Mar 11 15:59:02 * rich0 is remined of attack plan R, R as in Robert... Mar 11 15:59:08 next: Make all cosmetic repoman warnings fatal Mar 11 15:59:21 * WilliamH abstains Mar 11 15:59:23 for the record Mar 11 15:59:31 WilliamH, okay noted WilliamH Mar 11 15:59:35 that was for previous issue Mar 11 15:59:49 WilliamH, understood Mar 11 16:00:10 okay so this comes from patrick, and he wants all repoman cosmetic warnings to be fatal Mar 11 16:00:26 discussion? Mar 11 16:00:44 I've seen way too many false positives for both whitespace and quoting issues, to make these warnings fatal Mar 11 16:00:53 The only specific suggestion I'd entertain was unused local useflag descriptions in metadata.xml, but I'm not sure if that has any risk of false positives. Mar 11 16:01:01 fatal for use flag descriptions is fine Mar 11 16:01:28 i agree with ulm, too many false positives but use flags is fine Mar 11 16:01:31 I'm also fine with devs forcing that situation anyway if the removal is only temporary. Mar 11 16:02:02 e.g. patches or config files inlined in here-documents are bound to produce false whitespace warnings Mar 11 16:02:14 ulm, good point Mar 11 16:02:19 how about this: Mar 11 16:02:45 "make all repoman warnings where with current portage tree no false positives are known fatal" Mar 11 16:02:59 not sure about that Mar 11 16:03:04 I think that is pretty broad. Mar 11 16:03:08 "no false positives" might be vague Mar 11 16:03:22 dilfridge: that would include -j1 Mar 11 16:03:23 That includes deprecated eclasses, etc. Mar 11 16:03:41 Warnings are warnings for a reason. Mar 11 16:03:42 true, makes no sense. Mar 11 16:03:55 Devs need to use their brains. Mar 11 16:04:18 must we vote about this at all? Mar 11 16:04:28 if they didn't then we'd just write an ebuild writing utility Mar 11 16:05:00 ready for the vote? Mar 11 16:05:02 who in his right mind would see a use flag description warning and not fix it? Mar 11 16:05:10 we could just make an informal request to the portage team to turn the screw in future releases Mar 11 16:05:22 ulm, i don't always on my overlay when i copy a package form the tree Mar 11 16:05:43 blueness: yeah, in that situation it makes some sense Mar 11 16:06:04 Council to repoman: we're tired of being the only ones made to dance... Mar 11 16:06:04 i only want to change one ebuild, and keep everything else the same, you get the idea Mar 11 16:06:45 i'm getting the sense the council isn't for this ... no voices in favor Mar 11 16:06:55 blueness: good point - as an arch tester you get repoman warnings all the time Mar 11 16:07:03 yep Mar 11 16:07:11 i did my share of that Mar 11 16:07:58 okay lets vote: vote yes if you are in favor of "Making all cosmetic repoman warnings fatal" Mar 11 16:08:15 * rich0 no Mar 11 16:08:17 * blueness no Mar 11 16:08:20 * WilliamH no Mar 11 16:08:21 * dilfridge abstains Mar 11 16:08:40 ulm, dberkholz ??? Mar 11 16:09:18 dberkholz|mob, ulm ??? Mar 11 16:09:30 * ulm no Mar 11 16:09:51 dberkholz dberkholz|mob dilfridge dilfridge|mobile dleverton_ DrEeevil Mar 11 16:09:59 even without dberkholz the motion fails Mar 11 16:10:10 okay next item ... Mar 11 16:10:13 drum roll Mar 11 16:10:19 Adherence to FHS standards in Gentoo: putting config files int /etc Mar 11 16:10:49 this also comes from patrick, who wants us to adhere to at least part of FHS standards Mar 11 16:10:49 I think config files intended to be user-editable should go in /etc. Mar 11 16:10:55 namely config files in /etc Mar 11 16:10:57 only Mar 11 16:11:09 The stuff that was under debate is really just config defaults, intended to be overridden in /etc. Mar 11 16:11:09 Here's the thing. Mar 11 16:11:23 rich0: has it correct. Mar 11 16:11:42 Every binary has config defaults stored in /usr - you just normally have to edit the C source to change them. Mar 11 16:11:43 These files that are not going in /etc are Mar 11 16:11:45 This kinda conflicts with our policy to stick with upstream. (As much as it pains me.) Mar 11 16:11:48 (guys, excuse me for a few mins while i run to the washroom) Mar 11 16:11:59 supplied by the packages and are not to be edited by the user. Mar 11 16:12:01 The newer trend is to move all the constants into a rule file in /usr, and allow overrides in /etc. Mar 11 16:12:30 config files go to CONFIG_PROTECTed locations like /etc Mar 11 16:12:36 whereas config defaults are static files and don't need config-protection Mar 11 16:12:52 so they can go to /usr/share or /lib Mar 11 16:13:09 Certainly room for user education here, however, as I can see why there is confusion. IF somebody does edit something in /usr it could get clobbered in an update. Mar 11 16:13:24 udev rules are as much config files as .desktop files in /usr/share/applications Mar 11 16:13:43 If there is stuff config-protected in /usr that might suggest an area for improvement. Mar 11 16:13:45 back Mar 11 16:14:06 mgorny: udev rules can be overriden in /etc. I'm not sure if that is true of .desktop files. Mar 11 16:14:21 mgorny: what the ones are in /lib/udev or /usr/lib/udev are defaults. Mar 11 16:14:23 I don't really think of desktop files as "configuration" though. Mar 11 16:14:48 By that logic maybe I want to tweak one of my fonts. :) Mar 11 16:14:54 rich0: there are things like /usr/share/gnupg/ and /usr/share/config/, in fact :( Mar 11 16:15:40 * Arfrever (~Arfrever@apache/committer/Arfrever) has joined #gentoo-council Mar 11 16:15:48 Patric's goal with this was to force us to move /lib/udev/rules/d/* to /etc/udev/rules.d Mar 11 16:16:01 I'm flat against doing that with udev rules. Mar 11 16:16:12 s#rules/d#rules.d# Mar 11 16:16:14 i have to agree Mar 11 16:16:17 I might feel differently if udev didn't already have an /etc-based solution Mar 11 16:16:22 While a clear separation would be nice, I fear it will force us into an unmaintainable mess of patching. Mar 11 16:16:23 as long as these files are static they're fine in /lib Mar 11 16:16:30 we used to do it that way with udev rules Mar 11 16:16:41 I finally cleaned out the last cruft from that some time ago Mar 11 16:17:03 Also if we did this /usr/lib/systemd/system/* would have to go to /etc/systemd/system/* Mar 11 16:17:09 * ulm hopes that nobody will suggest creating /share Mar 11 16:17:45 * rich0 ducks Mar 11 16:18:11 * WilliamH as against this because it will force a patching nightmare Mar 11 16:18:51 WilliamH, in eudev i could easily change it from //lib/udev/rules.d to /etc/udev/rules.d but this defeats the stacking structure of config files Mar 11 16:19:10 we want the default rules to not be touched Mar 11 16:19:15 these are in /lib/udev Mar 11 16:19:19 blueness: that is what patrick is suggesting. he doesn't like the stacking structure. Mar 11 16:19:36 That's why I'm against this. Mar 11 16:19:49 WilliamH, the ambiguity hinges on "what is a config file" Mar 11 16:19:55 even KDE has such a stacking structure Mar 11 16:20:02 are the "default" rules config files Mar 11 16:20:05 i say no Mar 11 16:20:08 blueness: no Mar 11 16:20:10 Honestly, probably best to take FHS issues one-at-a-time Mar 11 16:20:12 (you can define overrides for user config files in /usr) Mar 11 16:20:16 they are static Mar 11 16:20:22 I'm sure there are some in the tree, but I'm hard-pressed to think of any big ones. Mar 11 16:20:45 I don't consider udev/systemd violations of FHS insofar as how they handle config files. Mar 11 16:21:16 amazingly enough that is one thing systemd does not violate ... Mar 11 16:21:16 rich0: that's why this issue is before us though; Patrick does. Mar 11 16:21:19 * blueness ducks Mar 11 16:21:26 i'm not interested in anything we can't get upstream as a build option Mar 11 16:21:35 WilliamH: well, he's welcome to his opinion :) Mar 11 16:21:46 we're not going to ban the practice though Mar 11 16:22:03 * WilliamH agrees Mar 11 16:22:24 okay it sounds to me like the council is against this motion Mar 11 16:22:35 Hey, if somebody has another example that is causing real problems they can feel free to bring it up, upstream or not. I just don't see any examples yet. Mar 11 16:22:40 ready to vote or more discussion? Mar 11 16:22:51 blueness: stick a fork in it Mar 11 16:22:54 * WilliamH ready to vote Mar 11 16:23:20 okay ... vote for "Adherence to FHS standards in Gentoo: putting config files int /etc". Vote yes if you want to see all config files in /etc. Mar 11 16:23:34 * ulm yes Mar 11 16:23:41 wait Mar 11 16:23:45 hehe Mar 11 16:23:47 wait Mar 11 16:24:01 waiting, did i say something ambiguous? Mar 11 16:24:01 i don't think that has enough nuance to it so i'm going to vote no Mar 11 16:24:02 given that a "config file" is a file intended to be modified by the user Mar 11 16:24:08 one does not simply walk into mordor. Mar 11 16:24:12 ^^ my vote above Mar 11 16:24:13 Don't like the wording of that. Ambiguous Mar 11 16:24:29 sorry guys, my bad, let me reword that given the discussion Mar 11 16:24:50 How about "Council does not feel additional policy required regarding config files in /etc. Specific issues not already discussed can be raised in future meetings." Mar 11 16:25:11 i support putting everything in /etc that upstream provides a way, or will accept a way, to put in /etc. Mar 11 16:25:17 * WilliamH likes rich0's wording Mar 11 16:25:32 rich0, i think we need to have something in ther clarifying human editable config files versus default config files Mar 11 16:25:50 that was the error in my first wording Mar 11 16:26:15 Council does not feel additional policy required regarding config files in /etc. In particular packages that place config templates in /usr and allow overriding in /etc are fine. Specific issues not already discussed can be raised in future meetings. Mar 11 16:26:37 yeah Mar 11 16:26:41 rich0: s#/usr#/ or /usr# Mar 11 16:27:03 i was leaning towards patrick's idea until that distinction came to light Mar 11 16:27:19 okay revote: "Council does not feel additional policy required regarding config files in /etc. In particular packages that place config templates in /usr and allow overriding in /etc are fine. Specific issues not already discussed can be raised in future meetings." Mar 11 16:27:30 * rich0 yes Mar 11 16:27:31 * blueness yes Mar 11 16:27:35 * dilfridge yes Mar 11 16:27:41 what about /lib? Mar 11 16:27:58 Again, if somebody finds some other case they are concerned with they can raise it - upstream-supported or not. Let's fix actual issues though and not debate theology. Mar 11 16:27:59 ulm, i think its implicit in there Mar 11 16:28:02 wasn't it started by files in /lib? Mar 11 16:28:13 udev rules are in /usr Mar 11 16:28:23 rich0, no in /lib/udev Mar 11 16:28:23 rich0: no they aren't Mar 11 16:28:28 ah Mar 11 16:28:54 so: s#/usr#/lib or /usr/share# Mar 11 16:29:00 okay waiting for a vote form ulm and dberkholz Mar 11 16:29:07 and WilliamH Mar 11 16:29:11 "Council does not feel additional policy required regarding config files in /etc. In particular packages that place config templates in /usr or /lib* and allow overriding in /etc are fine. Specific issues not already discussed can be raised in future meetings." Mar 11 16:29:25 okay, better Mar 11 16:29:37 * ulm yes on rich0's wording Mar 11 16:29:45 * WilliamH votes yes on rich0's last wording Mar 11 16:29:45 * rich0 yes Mar 11 16:29:45 * blueness yes Mar 11 16:30:07 * dilfridge yes on rich0's wording Mar 11 16:30:14 dberkholz, ? Mar 11 16:30:33 okay rich0 motion carries Mar 11 16:30:44 meh Mar 11 16:30:52 meh? Mar 11 16:30:56 = abstain? Mar 11 16:31:04 i don't care, sure abstain i guess Mar 11 16:31:08 lol Mar 11 16:31:14 for the record, i don't know if y'all have seen it but here's the fhs 3.0 beta: http://www.linuxbase.org/betaspecs/fhs/fhs/index.html and the announcement: http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs-30-draft-1 Mar 11 16:31:35 dberkholz, interesting, ididn't know that Mar 11 16:31:38 i'll be sure to look Mar 11 16:31:51 okay next item Mar 11 16:31:52 it's surprisingly hard to chase down Mar 11 16:31:57 Bugs assigned to Council Mar 11 16:32:08 Bug #503382 - Missing summaries for 20131210, 20140114, and 20140225 council meetings Mar 11 16:32:10 blueness: https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council Mar 11 16:32:11 summaries are in progress from my meetings Mar 11 16:32:15 Bug #477030 - Missing summary for 20130611 council meeting Mar 11 16:32:17 blueness: https://bugs.gentoo.org/477030 "Missing summary for 20130611 council meeting"; Doc Other, Project-specific documentation; CONF; ulm:council Mar 11 16:32:31 so we have some missing summaries Mar 11 16:32:45 i mostly finished them but haven't yet gotten them finalized and committed Mar 11 16:32:51 !note betelgeuse bug 477030 Mar 11 16:32:51 fine, dilfridge Mar 11 16:32:52 we need a secretary again Mar 11 16:33:20 hadn't someone volunteered for the 20130611 summary? Mar 11 16:33:39 ulm, i thought it was under control, but i don't know what's going on there Mar 11 16:34:16 wasn't someone going to chase down betelgeuse? Mar 11 16:34:36 scarabeus wanted to do this Mar 11 16:34:39 k Mar 11 16:35:08 yeah i remember now, but he's awal Mar 11 16:35:10 awol Mar 11 16:35:31 so looks there's no progress on the 2013 one, and donnie's summaries are on their way Mar 11 16:35:37 yep Mar 11 16:35:46