rich0 14/05/14 20:22:59 Added: 20140513-summary.txt 20140513.txt Log: Add May council meeting logs/summary.
Revision Changes Path 1.1 xml/htdocs/proj/en/council/meeting-logs/20140513-summary.txt file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20140513-summary.txt?rev=1.1&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20140513-summary.txt?rev=1.1&content-type=text/plain Index: 20140513-summary.txt =================================================================== Summary of Gentoo council meeting 13 May 2014 Agenda ====== 1. Roll call 2. Package Default USE Flags / Security 3. Non-upstream pkg-config 4. Bugs assigned to Council 5. Open floor 1. Roll call ============ Present: blueness, dberkholz, rich0, scarabeus, ulm Absent: dilfridge, williamh 2. Package Default USE Flags / Security ========================================================================= The council discussed default USE flags, in-particular including those of openssl and openssh [1 and 2]. The council felt that this should be left to the maintainer's discretion. "Per existing policy, the council leaves the default USE flags to the discretion of the maintainer, but encourages following upstream when there is no reason to do otherwise." Aye: dberkholz, rich0, scarabeus, ulm Not present for vote: blueness [1] - https://bugs.gentoo.org/show_bug.cgi?id=507130 [2] - https://bugs.gentoo.org/show_bug.cgi?id=507210 3. Non-upstream pkg-config ========================================================================= The council felt unanimously that an outright ban on non-upstream pkg-config files was inappropriate. It was felt that any sensible policy would leave it to the maintainer's discretion. The exact wording of the recommendations was deferred to the lists/etc. "The council agrees to revise the devmanual policy regarding pkg-config files to set guidelines for non-upstream pkg-config files but to leave the inclusion up to the maintainer's discretion. Wording will be worked out following the meeting, and in the meantime the changes introduced in bug 445130 will be reverted." Aye: blueness, dberkholz, rich0, scarabeus, ulm 4. Bugs assigned to Council =========================== Bugs 503382 and 477030 are for missing summaries - those responsible are reminded to write them up. Bug 498332 was discussed and it was not felt that it was necessary for Council to remain CC'ed. A note to this effect will be posted on the bug by rich0. 5. Open floor ============= No issues were brought forward. Summary submitted by Richard Freeman <ri...@gentoo.org> 1.1 xml/htdocs/proj/en/council/meeting-logs/20140513.txt file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20140513.txt?rev=1.1&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20140513.txt?rev=1.1&content-type=text/plain Index: 20140513.txt =================================================================== [15:01:40] <rich0> Roll call: blueness, dberkholz, dilfridge, scarabeus, ulm, williamh [15:01:49] -*- ulm here [15:01:56] <dberkholz> hi [15:02:01] -*- rich0 notes email from williamh expecting to not be present [15:02:39] <rich0> ulm, dilfridge? [15:02:47] -*- ulm still here :) [15:03:01] <scarabeus> ulm: too tiny to be noticed i guess :P [15:03:01] <rich0> err, blueness... [15:03:13] <rich0> I knew I was missing two more... [15:03:37] <rich0> Ok, blueness, williamh, dilfridge not present. We can start [15:03:54] <rich0> Topic #1: Package Default USE Flags / Security [15:04:30] <rich0> tls-heartbeat and hpn were specific examples brought up, but the general question is what should our default USE flags be from a security standpoint. [15:04:54] <rich0> Any comments? I posted mine on the list. [15:05:05] <ulm> maintainers should go with the upstream default [15:05:23] <ulm> but finally it's the maintainer's choice what flags to enable [15:05:24] <rich0> So, that would be tls-heartbeat on, and hpn off. [15:05:42] <ulm> yep [15:05:57] <rich0> My personal sense is maintainer's discretion, with the principle of following upstream. [15:05:57] <scarabeus> up to the dev honestly [15:06:15] <rich0> We'll never come up with a blanket policy that makes sense without some discretion. [15:07:09] <rich0> Ok, how about "The council leaves default USE flags to the discretion of the maintainer, but encourages following upstream when there is no reason to do otherwise." [15:07:45] <ulm> sounds good [15:07:54] <rich0> Ok, do we want to vote? [15:08:24] <rich0> If so, aye for me. [15:08:43] <scarabeus> aye from me [15:08:49] <ulm> yes [15:08:55] <rich0> dberkholz ? [15:09:16] <dberkholz> hmmm [15:09:44] <dberkholz> that doesn't even sound like we're saying anything new [15:09:52] <dberkholz> i don't know why we would vote on it at all [15:10:19] <rich0> I understand - I just see that as our conclusion, so that we can document that we agree to leave things alone. [15:10:43] <dberkholz> sure. maybe we can note that we're supporting existing policy with that statement rather than changing [15:11:07] <dberkholz> prepend it with "As per existing policy," or something [15:11:19] <rich0> Ok, how about, "Per existing policy, the council leaves the default USE flags to the discretion of the maintainer, but encourages following upstream when there is no reason to do otherwise." [15:11:46] <dberkholz> good for me. [15:11:52] <ulm> +1 [15:11:59] <rich0> +1 for me as well [15:12:05] <rich0> scarabeus? [15:12:29] <scarabeus> +1 [15:12:33] <rich0> Ok, topic #2: Non-upstream pkg-config [15:12:54] <rich0> A few more ideas circulated on the lists in addition to the ones in the agenda. [15:13:31] <rich0> Options also include controlling the installation of non-upstream pkg-config files via a USE flag, or sticking them in a special path. [15:14:35] <rich0> I think the USE flag idea isn't a terrible one, even though in general I'm not a fan of controlling single file installtion via USE flags this seems a bit different and INSTALL_MASK won't work. [15:15:03] <dberkholz> funny, i don't like the USE flag idea [15:15:09] <scarabeus> that is bad with the use [15:15:10] <rich0> Thoughts? I'm not a big fan of a complete ban. [15:15:43] <scarabeus> it should not be banned either, it should be installed if we want it per maitnainer decision, but he needs to talk with other distros and have them do the same darn thing [15:15:57] <scarabeus> stupid would be each distro providing own pc [15:16:20] <scarabeus> if the pc make life easier why not have it [15:16:20] <rich0> I do agree that alignment with other distros should be a consideration. In practice, only the maintainer could make that call. [15:16:40] <ulm> I don't see this as anything were the council should intervene [15:16:53] <ulm> leave it to qa on a case by case basis [15:16:55] <dberkholz> +1 ulm [15:16:56] <rich0> Not sure if we can send upstream a lart-o-gram. [15:17:16] <ulm> and general policy is that patches should be sent upstream if possible [15:17:30] <rich0> ulm: nothing new there [15:17:33] <ulm> I don't see how pkgconfig files are special in this respect [15:17:36] <creffett|irssi> (qa hat on) I don't even see why this needs to be a QA problem, I consider this equivalent to, say, patching to fix a build--upstream if you can [15:17:39] <creffett|irssi> what ulm said [15:18:21] <rich0> I can understand how this calls for more care than just patching a build system, since we're basically defining a distro-specific interface of sorts. [15:18:49] <rich0> However, I think that any sensible policy is going to leave this to maintainer's discretion. We can give guideance, but we can't come up with some kind of blanket rule. [15:19:21] <rich0> If we went with this it does mean a change to the devmanual, which apparently outright bans them. [15:19:43] <scarabeus> agree it is like any other build patch; only this time it is more required to coordinate with others [15:20:39] <rich0> Anybody have the devmanual link? [15:20:54] <ulm> the patch is in bug 445130 [15:20:56] <willikins> ulm: https://bugs.gentoo.org/445130 "document that pkgconfig files should not be modified/added/renamed"; Doc Other, Devmanual; RESO, FIXE; hasufell:devmanual [15:21:04] <ulm> introduced quite recently [15:21:29] <ulm> and tbh, I don't understand why it was accepted without much discussion [15:22:05] <rich0> Ok, do we want to work out exact wording now? [15:22:17] <creffett|irssi> ulm: because it was directly committed [15:22:20] <rich0> Or just agree on the change with wording to be worked out along these lines? [15:22:54] <scarabeus> sweet didn't know this rule [15:23:04] <scarabeus> revert and write better wording would be best [15:23:34] <rich0> If so, how about, "The council agrees to revise the devmanual policy regarding pkg-config files to set guidelines for non-upstream pkg-config files but to leave the inclusion up to the maintainer's discretion. Wording will be worked out following the meeting." [15:24:03] <rich0> We could revert in the interim, though I don't see any rush. [15:24:09] <ssuominen> having pkg-config files should be recommended, it's the only way to solve some of the current build problems that works for every scenario [15:24:23] <rich0> I'm not opposed to reverting for now. [15:24:49] <ssuominen> if upstream doesn't provide them, we should, just like we patch important bugs even if upstream refuses them [15:24:55] <rich0> If we do that, then: "The council agrees to revise the devmanual policy regarding pkg-config files to set guidelines for non-upstream pkg-config files but to leave the inclusion up to the maintainer's discretion. Wording will be worked out following the meeting, and in the meantime the changes introduced in bug 445130 will be reverted." [15:24:56] <willikins> rich0: https://bugs.gentoo.org/445130 "document that pkgconfig files should not be modified/added/renamed"; Doc Other, Devmanual; RESO, FIXE; hasufell:devmanual [15:25:42] <rich0> Do we really want to recommend ALWAYS creating a pkg-config file? [15:25:43] <ulm> rich0: +1 [15:26:00] <ulm> (on the wording) [15:26:06] <dberkholz> works for me [15:26:40] <rich0> scarabeus, you OK with that wording for now? [15:26:47] <ssuominen> not always, but when there is need to have list of libraries used for static linking *somewhere* (ie. Libs.private:) over even if package provides foobar-config [15:27:04] -*- blueness is here [15:27:45] <scarabeus> fine [15:27:55] <rich0> blueness: do you want to vote RE pkg-config? [15:27:57] <rich0> The proposal is: [15:28:05] <rich0> "The council agrees to revise the devmanual policy regarding pkg-config files to set guidelines for non-upstream pkg-config files but to leave the inclusion up to the maintainer's discretion. Wording will be worked out following the meeting, and in the meantime the changes introduced in bug 445130 will be reverted." [15:28:06] <willikins> rich0: https://bugs.gentoo.org/445130 "document that pkgconfig files should not be modified/added/renamed"; Doc Other, Devmanual; RESO, FIXE; hasufell:devmanual [15:28:38] <blueness> thanks rich0 let me read that bug [15:29:08] <rich0> blueness: go ahead. https://445130.bugs.gentoo.org/attachment.cgi?id=330930 is basically the gist of it [15:30:03] <blueness> rich0, i'm okay with the council's position [15:30:09] <blueness> ie that wording [15:30:35] <rich0> ok, anything else on that? Otherwise I think the new guildelines will benefit from general bikeshedding, and we've already outlined where we're going. [15:31:21] <rich0> Ok, if nothing else... [15:31:22] <blueness> rich0, the only thing i couldn't figure out from the emails is where this became an issue [15:31:38] <ulm> rich0: do we vote on this [15:31:49] <rich0> Ah, I counted those as votes. [15:31:53] <ulm> yes from me, too [15:32:00] -*- blueness yes [15:32:03] -*- scarabeus yes [15:32:12] -*- rich0 yes (for the record) :) [15:32:39] <dberkholz> yes again [15:32:53] <ulm> commit reverted: http://git.overlays.gentoo.org/gitweb/?p=proj/devmanual.git;a=commit;h=41e625daa4be537f934ba50276a97c97b7f3fd85 [15:32:54] <rich0> blueness: the actual issue is that if somebody uses gentoo they might leverage a pkg-config file in their own software's build system, and then have it break on other distros [15:33:34] <rich0> Or maybe upstream finally issues one and something changes, breaking reverse deps. [15:34:08] <blueness> rich0, i guess i'm asking if this happened somewhere [15:34:14] <rich0> There are pros and cons either way, but I think that they're helpful more often than not. [15:34:20] <rich0> I doubt it. [15:34:23] <blueness> k [15:34:33] <rich0> And if you find out your build system breaks on slackware or something, then you fix it. [15:35:03] <rich0> Ok, moving on... [15:35:07] <blueness> rich0, the reason i'm asking is because i was about to remove curl-config but didn't -> https://bugs.gentoo.org/show_bug.cgi?id=497956 [15:35:11] <blueness> *for the records. [15:35:18] <blueness> okay sorry let's move on ... [15:35:58] <rich0> Ok, open bugs. [15:36:11] <rich0> Two are missing summaries - other than another ping, anything to talk about with those? [15:36:27] <rich0> For bug 498332, is there any reason we're still CC'ed? [15:37:00] <rich0> I think that one is basically resolved as far as we're concerned. Non-stable archs can use stable flags if they want, but maintainers can ignore them. [15:37:02] <scarabeus> no idea why we are cced :) [15:37:19] <rich0> Ok, I'll leave a note on 498332 and remove us. [15:37:30] <ulm> +1 [15:38:02] <rich0> Ok, I think that wraps up bugs. AOB? [15:38:40] <rich0> If not, moving to open floor. Anybody have anything to bring up? [15:39:44] <ulm> just a heads up, I intend to come up with a feature list for eapi 6 fro the next meeting [15:40:09] <rich0> looks like we get to go out with a ban [15:40:10] <blueness> ulm, okay [15:40:13] <rich0> err, bang [15:40:21] <blueness> rich0, fizzle/ [15:40:27] <blueness> :( [15:40:29] <blueness> :) [15:40:33] <rich0> if we don't like the feature list, we can always ban you from brining forward mroe [15:40:36] <blueness> (i can't type) [15:41:05] <rich0> Another question - do we need to do something to plan for elections? [15:41:34] <rich0> Can't believe it has been a year... [15:42:16] <rich0> Looks like last year's results were never posted. [15:42:16] <blueness> is there a committee that takes care of elections? [15:42:29] <scarabeus> blueness: election team has to handle it [15:42:33] <scarabeus> not our job luckily ;D [15:42:37] <blueness> k [15:42:45] <blueness> scarabeus, well it can't be [15:42:53] <rich0> Ok, I'll ping them and remind them to start planning. Looks like we still have a month before nominations start. [15:43:17] <rich0> And I'll bug them to post their summaries too. [15:43:32] <rich0> Ok, if nothing else, then I'm chairing next month, and will post the logs/summary. [15:43:45] <dberkholz> thanks rich0! [15:43:47] -*- rich0 bangs the gavel
