[20:00:39] ahoj [20:00:41] :) [20:00:45] hi all [20:00:46] roll call [20:00:48] that is czech hi :) [20:01:03] ho ho ho [20:01:06] -*- dilfridge here [20:01:21] -*- rich0 here [20:01:26] -*- ulm here [20:02:17] just pinged blueness on #-dev [20:02:33] --> _AxS_ (~axs@gentoo/developer/axs) hat #gentoo-council betreten [20:02:54] let's give him till 1905, then we'll move on [20:03:13] --> few_ (~few_@88.150.18.76) hat #gentoo-council betreten [20:03:54] --> grknight (~Thunderbi@50.120.197.130) hat #gentoo-council betreten [20:04:17] -*- WilliamH here [20:05:58] alright, let's get into the agenda [20:06:16] first topic is notifications for the EAPI=5 profile flip [20:07:21] one remark [20:07:45] as ciaran states, there's not really an EAPI for the whole profile tree, just for single directories [20:07:57] so, to clarify this, I'd suggest [20:08:21] * dberkholz has changed topic for #gentoo-council to: " Next meeting: 14 Jan 2014 at 1900 UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 | http://wiki.gentoo.org/wiki/Project:Council | Agenda: http://thread.gmane.org/gmane.linux.gentoo.project/3247" [20:08:41] "Making the whole profile tree EAPI=5" means, "anyone can increase the eapi in any profile directory to 5 if the features are needed" [20:08:50] that's kind of the opposite [20:08:56] the decision was default to 5 [20:09:00] ok [20:09:09] then we have to place an eapi 5 file in every dir [20:09:11] so what i think we should do is provide 30-day notice for people to drop in an older eapi file, then put 5 into anything that's left empty [20:09:22] fine with me too [20:09:28] dberkholz: ++ [20:09:36] why would we place an eapi file in dirs where the features are not needed? [20:10:03] <_AxS_> what will this do to those running say, pkgcore, that doesn't support EAPI5 yet; this would effectively make any profile incompatible with it, no? [20:10:16] the vote on that topic was a year ago ulm [20:10:37] _AxS_: yes. however, all non-deprecated profiles are already incompatible for a year. [20:11:11] <_AxS_> dilfridge: true, but one could at least make their own profile that inherits from base, if base isn't EAPI5 [20:11:32] Do we REALLY want to support non-EAPI5 indefinitely? [20:11:38] the whole point of the exercise was to make base eapi=5 capable [20:11:46] (and all the other places) [20:11:50] There was a year's notice, and we're giving another month's notice... [20:12:09] You can always make an overlay that is EAPI4 for whatever subset of the tree still works on EAPI4-- [20:12:24] which is probably not much [20:12:39] if we keep rehashing and pushing off previous council decisions whenever we actually have to take action on them, we're not going to get anywhere [20:12:47] It just doesn't seem all that feasible to avoid EAPI5 as a user, and it just doesn't seem like there is any real reason to support it. [20:13:01] dberkholz: can you point me to the place where we have decided that we would put an eapi 5 file in every profile directory? [20:13:08] -*- WilliamH agrees with dberkholz [20:13:12] If I thought the previous decision didn't make sense I'd be all for questioning it, but I think they made the right call... [20:13:12] I cannot find it in the 20130109 log [20:13:20] *0108 [20:13:28] Deadlines should mean something, unless it is suicidal to hold to them. [20:13:34] -*- WilliamH agrees with rich0 [20:14:01] Vote on proposal "Stable USE masks in the main portage tree" by [20:14:01] Michał Górny [1]. There are three suggested approaches: [20:14:01] 1) by adding new profiles requiring EAPI=5, requiring all users to [20:14:01] change, and then deprecating the older profile trees [if chosen; a [20:14:01] subsequent vote on the timeframes involved will follow] [20:14:01] [...] [20:14:11] The council agreed unanimously to vote between the three proposed solutions. [20:14:11] Solution #1 won with 7 votes. [20:14:17] deadlines are deadlines; if they haven't been able to fix it in time it is on them we don't have to hold back and wait for them [20:14:42] i agree with ya guys, deadlines are deadlines as WilliamH says :) [20:14:48] ulm: that's an implementation detail. the vote was "a 1 year deprecation period for current EAPI<5 profile trees" [20:15:02] as per http://www.gentoo.org/proj/en/council/meeting-logs/20130108.txt [20:15:33] and further clarification of "Removal of the old EAPI<5 profile trees." [20:15:46] dberkholz: still doesn't imply that every little dir needs the file [20:15:50] I would interpret this as "it's allowed to use eapi 5 everywhere", not "everything has to be eapi 5"... [20:15:57] dilfridge: right [20:16:29] anything else makes things more confusing for developers at little tangible benefit [20:16:29] the net effect on users is the same since for sure we'll do it in base, and the arch teams are also interested for their directories [20:17:02] -*- WilliamH agrees with dberkholz there has been anple time; let's make everything eapi 5 [20:17:25] meh I dont care between the two options, that difference is not related in any way to the deprecation timeframe [20:17:28] yeah, just put the file where it's needed [20:17:40] no need to spam the tree with 600 files [20:17:53] WE're talking about the profile, not all packages. [20:18:10] i didn't realize we had 600 profiles but thanks for the hyperbole. [20:18:18] $ find /usr/portage/profiles/ -type d | wc -l [20:18:20] 609 [20:18:20] Individual ebuilds can be non-EAPI5. They just will not work on a non-EAPI5 PM due to the profile unless the user uses an overlay/etc. [20:18:24] it's 609 directories [20:18:39] The number doesn't really concern me. [20:18:45] well, some are to be removed, tbh [20:18:49] Just ignore the commit messages for a day, etc. :) [20:18:55] but it's some 400 still [20:19:00] question... [20:19:17] If we make base eapi 5, doesn't that mean that everything that inherits from it is eapi 5? [20:19:25] Set it once in base, or 609 times, the technical impact seems to be the same to me. [20:19:27] unfortunately not [20:19:32] ^^ WilliamH [20:19:39] no, pms says otherwise [20:19:43] no, because the eapi is not inherited from parents [20:19:45] however [20:19:49] So, just conform to PMS and do it 609 times. [20:20:05] this has no meaning w/r to deprecation, since the package manager will have to support eapi 5 anyway [20:20:15] that's 2.5 MB of disk space on ext4 [20:20:24] so? [20:20:40] -*- ulm just noting [20:20:49] ulm: maybe it should be fixed in pms? [20:20:58] i don't think we're getting anywhere with this endless argument so why don't we vote on it, again [20:21:32] vote: 30-day notice for people to add an eapi file to profiles, then we're dropping eapi 5 into any empty ones [20:21:42] WilliamH: not sure if it can be fixed easily [20:21:52] not immediately, at least [20:22:15] dberkholz: eh, that makes no sense at all [20:22:27] why would we want eapi < 5 files anywhere? [20:23:01] if we put a file, it should be newest eapi [20:23:26] how about two separate votes, as follows: [20:23:29] newest would be the default, this provides an opt-out for anyone with a significant reason otherwise [20:23:30] -*- ulm is just concerned about it being several 100 files [20:23:39] who in the world cares about several hundred files [20:23:46] we have tens of thousands in the tree, it's a couple of MB of space [20:23:56] a) 30-days notice, then everything in profiles may require eapi 5 [20:24:06] b) drop eapi 5 files everywhere? [20:24:16] dberkholz: we would have one million if we were always as careless :p [20:24:44] --> rafaelmartins (~rafael@gentoo/developer/rafaelmartins) hat #gentoo-council betreten [20:25:00] Why two votes? why not just a vote that in 30 days we will drop eapi 5 files everywhere? [20:25:06] dilfridge: sounds good [20:25:36] I don't care how we vote. However, if we vote yes and then no I think we create a potential PMS mess. [20:25:48] does anybody really think we should do a but not b? [20:25:59] rich0: yes ;) [20:26:18] let's think, what is the difference on the profile level exactly? [20:26:21] I mean, sure, I wish PMS were otherwise, but do we want to try to change it before we implement this? [20:26:23] <_AxS_> ulm: fwiw, currently there are 265'ish 'eapi' files in profiles/ , so there would only actually be about 357 new additions.. [20:27:15] -*- WilliamH thinks we should just give 30 days then do b [20:27:21] dilfridge: it specifies how the contents of the particular dir is read [20:27:29] <_AxS_> ulm: plus, technically we can remove a bunch of files after everything's eapi5 right? since anything related to legacy (non-eapi5) profiles no longer has a point being in profiles/ [20:27:35] no influence on parents or children [20:28:26] _AxS_: right [20:28:44] _AxS_: good point, plus for every one of those items there is the directory tree, parent records, and other files in the tree. So, this is adding 350 files to a collection of thousands [20:28:59] rrriight... slowly I'm getting convinced that placing eapi 5 everywhere is the better solution. [20:29:31] I'm all for finding a better way to handle profiles long-term, but that seems like a different issue [20:29:43] dberkholz: how about "30-day notice, then we're dropping eapi 5 into any profile dir"? [20:29:56] rich0: maybe the real issue is us having too many profiles [20:30:14] ulm: that's a separate issue... [20:30:19] actually that is another point, which we sshould immediately address after this one :] [20:30:35] because the 10.0 profiles have no reason to exist then anymore [20:30:41] i have an idea! let's fix every problem with gentoo before we end this council meeting! [20:30:46] :P [20:31:00] your turn mr chair [20:31:08] if we just keep it open and let people go in and out for the next year, i bet we could do it. [20:31:47] ok, can i just get a quick sense of who's opposed in theory to dropping eapi 5 files into every profile in 30 days? [20:31:52] dberkholz: so is dilfridge's statement abov what you were proposing we vote on? [20:32:05] not a formal vote, since it's not carefully phrased [20:32:35] -*- dilfridge is happy with both versions, but slowly thinking that making every dir eapi5 is the cleaner solution [20:32:37] dberkholz: and update existing eapi files to 5, too? [20:32:49] ulm: probably a good idea [20:33:02] everything eapi5, minimize complexity [20:33:46] "big untested change" though [20:34:13] I'm in favor of dumping eapi5 in every dir in 30 days [20:34:29] It isn't any uglier than find /usr/portage/profiles [20:34:30] -*- WilliamH is in favor [20:34:31] yeah, let's do it then [20:34:33] it would save devs from looking up the eapi for every dir [20:34:44] good point [20:34:55] alright, here's our vote: we will send 30-day notice and then switch all profiles to eapi 5 [20:35:04] -*- WilliamH yes [20:35:08] s/profiles/profile directories/ [20:35:13] -*- dilfridge yes [20:35:20] *sigh* [20:35:22] -*- ulm yes [20:35:27] yes from me [20:35:42] ulm: ha, i'll buy you a beer or other beverage at fosdem [20:35:56] --> blueness (~blueness@gentoo/developer/blueness) hat #gentoo-council betreten [20:36:03] damn! off by 1 hour [20:36:18] hi blueness :) [20:36:19] yes [20:36:27] blueness: no problem - you can tackle fixing all the profiles after we leave as pennance. [20:36:33] I volunteer do the stuff [20:36:36] i'm so sorry guys, i miscalculated UTC [20:36:47] (did the last changes too, so...) [20:36:54] blueness: just in time to get your voice heard on the vote: we will send 30-day notice and then switch all profiles to eapi 5 [20:37:04] dberkholz, definite yes on that [20:37:15] -*- rich0 yes [20:37:43] dilfridge: i might have to duel you for those rights, i need to do some committing or i'll get rusty =) [20:37:49] hehe [20:38:09] do we need to vote on the following cleanup? (2 parts, [20:38:24] a) move eapi-5-files/* to a better place [20:38:29] b) remove 10.0 profiles [20:38:31] )? [20:38:47] dilfridge: just do it [20:38:50] ok [20:38:52] no problem [20:39:06] that's just implementation details, don't think we should care [20:39:40] yay, someone owes me beer at fosdem or similar :) [20:39:52] i've got ya. [20:39:55] :) [20:40:03] cool, next topic [20:40:08] none of you both, someone else... :) [20:40:22] glep 1/2 updates: changes to the workflow and move to the wiki [20:40:35] in case anyone has missed it, creffett has posted an updated patch for GLEP 1: http://article.gmane.org/gmane.linux.gentoo.project/3241 [20:40:47] -*- creffett here if there are any questions [20:41:13] i liked the template, saw no problems with it [20:41:28] key changes are (1) submit gleps and modifications via bugzilla and (2) gleps will be stored on the wiki and formatted appropriately. some other minor ones [20:42:12] anyone have a problem with the proposal? [20:42:30] i'm good with it [20:42:31] -*- dilfridge likes it [20:42:40] my only comment is that I'd have left public-domain GLEPs alone and not change them to CC-BY-SA [20:42:40] -*- WilliamH is fine with it [20:42:44] but that's a detail [20:42:53] -*- scarabeus read it bit back and it looked quite fine [20:42:56] ulm, why? what's the concern? [20:43:02] ulm: does the lrelicense pose concern? [20:43:07] ulm: We could ask the authors if they are willing to change them if they are still around [20:43:15] no real concern [20:43:36] but also no reason to go from PD to more restrictive [20:43:54] but I won't oppose it [20:44:17] can't someone with pd remove the author? [20:44:24] there are some legal questions about whether it's even possible to put something into the public domain [20:44:28] that's the only difference i think there is between cc and pd [20:44:54] and it would be of value to unify all our content under a single license to make sure sharing stays easy [20:45:18] for example if someone pulls other wiki content into a public domain thing, suddenly they have to realize the license changes [20:46:17] the closest thing to public domain is probably CC0 but i don't think we specified that anywhere. [20:46:30] in principle you'd have to check in what legislation the author is located [20:46:32] but the intent should be clear if he has marked his stuff as PD [20:47:34] dberkholz: Do we need a formal vote on the proposed glep changes? [20:47:38] ulm, what i like about CC-BY-SA is that no one can legally "steal" your kudos [20:47:49] anyway, I'm still fine with the proposal as it is [20:47:53] 5 second read -> http://creativecommons.org/licenses/by-sa/3.0/ [20:47:57] so ulm is fine with the thing as is, nobody else has objected, let's vote [20:48:07] -*- blueness yes [20:48:10] -*- WilliamH yes [20:48:11] -*- ulm yes [20:48:13] -*- dilfridge yes [20:48:18] yes [20:48:25] yep [20:48:39] -*- rich0 yes [20:49:02] how about that, we're only 3 minutes behind schedule [20:49:08] on to the open bugs/issues [20:49:15] dberkholz: was this vote about GLEP 1, or 1&2? [20:49:33] 1 & 2 since 2 is just an templated example of following 1 [20:49:38] k [20:49:59] if anyone has an objected, speak now or forever hold your peace [20:50:03] objection* [20:50:36] re the open issues, i caught up with robbat2 about the gpg signing and he said he hasn't had time to submit it yet as a glep. creffett|irssi also noted that he wanted to run through the new process we just approved with it [20:50:54] so we're still waiting on external efforts for progress on that [20:51:35] one question i had which i never got answers was how gpg signign was going to be enforce [20:51:50] scripted or human (aka QA)??? [20:51:53] different problem [20:51:56] true [20:51:57] there's https://wiki.gentoo.org/wiki/Project:Gentoo-keys [20:52:40] dberkholz, thanks i didn't see that [20:52:55] it's in the references section of robbat2's draft glep =) [20:53:42] anyway, those folks are sorting out that side of things [20:54:30] I'm fine with the gist of what was propsoed for GPG. It just sounds like there are details to be worked out - it needs finalization before we can really give it a yes/no. I don't see anything objectionalbe so far. [20:54:40] ditto [20:55:06] i just made new keys last week as per the glep [20:55:42] alright, let's move on to the open floor [20:55:48] council members or others, any issues to raise? [20:56:09] I think I'm going to ask us to revisit our stabilization policy again. [20:56:26] bug 487332 is still open withno movement from arch teams [20:56:28] WilliamH: https://bugs.gentoo.org/487332 "sys-apps/openrc-0.12.4 and net-misc/netifrc-0.1 stable request"; Gentoo Linux, Keywording and Stabilization; CONF; williamh:openrc [20:57:05] imo there isn't a reason for arch teams to take so long on this stuff. :( [20:57:14] WilliamH: do you have something more concrete in terms of solutions? [20:57:24] <_AxS_> WilliamH: a lot of arch teams are short staffed, after ago left to pursue security only... [20:57:35] dberkholz: apply the package-by-package policy to all arch's [20:57:48] ago's doing security only now? [20:58:07] uh oh [20:58:18] he burned out [20:58:29] (i'm guessing) [20:58:57] the bug was filed only three months ago, and maybe one should be extra conservative with removing important packages like openrc [20:59:09] _AxS_: I understand that the arch teams are short staffed, but there has to be a better solution than maintainers being forced to keep old versions of packages around because of that. [20:59:12] because in this case it would hurt our users [20:59:22] <_AxS_> re ago; the move was more political, iirc.. some sort of conflicts with other devs.. [21:00:15] ulm: The package-by-package policy gives us permission to remove them from some arches after 90 days if there is no response, but it doesn't cover all arch's. [21:01:05] ulm: the arch teams do not necessarily prioritize important packages when they stabilize. [21:01:45] ulm: I pinged one of the arch teams on that bug on irc weeks ago and was just told that it takes time. [21:02:27] I guess my over all question is, if arch teams can't keep up, how relevant is their stable tree anyway? [21:02:31] WilliamH, okay how do you want to proceed? [21:02:36] WilliamH: this concerns ia64 only? [21:03:16] blueness: I"m not bringing anything here for a vote right now, just wanting to know what the rest of the council thinks... [21:03:42] ulm: let me pull up the bug again... [21:03:46] WilliamH: are you looking for something more along the lines of force-stabilizing newer versions or dropping stable? [21:04:39] We solved this in theory for a few specific archs, but we didn't make it a general policy, notably for x86/amd64. [21:05:36] ia64 is the one arch on that bug we solved it for. [21:05:57] We allow removal of stable versions on that arch. [21:06:42] It is the other arch's that haven't responded that we didn't do anything for, see the decision I pointed to in the bug. [21:07:47] what about a policy allowing devs to stabilize their own packages after a timeout? provided they ahve access to the arch [21:08:01] I understand that it's frustrating if the stablereq bug is just silent for ages [21:08:02] that sounds a bit dangerous [21:08:04] Would that help here? [21:08:15] blueness: it sounds like the way we did things before starting arch teams [21:08:24] dberkholz, and how did that go? [21:08:25] maybe we could go for something along the lines of "after x days, responsibility for the old stable ebuild will move from the pacakge maintainer to arch teams still relying on it" [21:08:30] Ultimately our choices are to help push along stable, or drop it. [21:08:36] Or keep the old package around. [21:08:47] although I'm not sure if that wouldn't lead to a total mess [21:08:49] blueness: reasonably well, it was largely a time sink for people who wanted to work on other things [21:08:55] Before we had arch teams we stabilized our own stuff after 30 days [21:08:56] Pushing potentially affects quality, dropping potentially destroys stable, keeping frustrates maintainers. [21:09:05] blueness: small quality hit but less than you might think [21:09:14] dberkholz, i self stabilize only hardened specific packages, hardened-sources and gradm [21:09:29] dberkholz, we could have a hybrid [21:09:43] If you drop stable entirely then basically all users end up moving to ~arch anyway, so is pushing harder on stable really an issue, such as by letting maintainer stabilize. [21:09:44] the self-stabilize after a timeout [21:09:44] ulm: No, keeping the old package still causes issues. [21:10:00] I thik letting the maintainer stabilize makes more sense than dropping stable entirely, especially for something like openrc. [21:10:09] rich0, i agree [21:10:17] No stable openrc basically means no stable at all. [21:10:57] I could go with a policy that allows maintainers to auto stabilize after a timeout. [21:11:01] <_AxS_> rich0: in the case of openrc (at least this time) it's not just openrc iirc -- kmod is also interrelated here. at any rate, often multiple packages need to go stable together. [21:11:07] the argument is always what stable means [21:11:18] there is no easy solution [21:11:24] does it mean actually tested by an arch user, or does it mean we try to provide you with something that we hope works [21:11:38] dberkholz: the former [21:11:44] with the aim of not breaking your upgrades vs not breaking your running system [21:12:00] ~arch is the latter [21:12:15] and no keywords or masked means we don't know if it works [21:12:20] i would prefer to drop stable vs force-stable untested software, then people have to explicitly ~arch it [21:12:29] +1 [21:12:57] dberkholz: good point [21:13:05] at least they know what they're getting [21:13:21] though that raises the question of whether stable packages can depend on unstable [21:13:29] alright WilliamH, do you want to kick off a discussion on -dev about a broader stabilization timeout for more arches and possible options [21:13:36] If not you end up cascade-destablilizing half the tree for a critical dep [21:13:40] we could discuss this for a long time here and not make much more progress i think [21:13:59] rich0: that question is sort of moot if you don't have stable openrc [21:14:02] ++ - I like the discussion so far, but this isn't going to get resolved in this meeting [21:14:24] dberkholz: I can do that, but it is basically two options. 1) allow maintainers to stabilize after 90 days, or 2) removing stable packages. [21:14:38] ulm: my thought is that there is a difference between package.keyword for just openrc vs having to accept ~arch for the entire tree [21:14:45] or 3), make maintainers leave old ebuilds around [21:14:52] rich0, should we bring this up on #gentoo-dev ... the fact that we don't ahve the manpower for stabilizatoin we used to [21:14:56] and see what the community wants [21:14:57] WilliamH: sure, but there could be nuances and we can at least hash it out. [21:15:07] ++ [21:15:24] we aren't going to make the problem go away with any decision - I think this needs some open discussion/debate [21:15:36] rich0: my point was that we don't need to care about tree consistency if important packages are missing from stable [21:16:04] for the affected archs, that is [21:16:20] ulm: the issue seems to be that arch teams don't see system packages as more important than others... [21:16:29] sure - I just wanted to toss it out there - it is a change in the letter of policy [21:16:42] ulm: I just remembered another part of the irc conversation I had. [21:16:45] letter of policy suggests that if you de-stabilize glibc you de-stablize 80% of the tree [21:16:49] that (@system) is actually a good point [21:16:52] WilliamH: was this ever different? [21:17:22] I still remember waiting for stabilisation for about one year in 2007 or 2008 [21:17:30] on minor arches [21:17:47] that's why i'm glad mips is ~arch! [21:17:53] it makes my life so much easeri [21:18:00] alright, let's wrap this meeting up [21:18:19] blueness: I think it even was on arm then ;) [21:18:22] thanks all for helping make progress on a couple of tricky and useful issues [21:18:46] till next time! i'm chair next time and then handing off to blueness for march [21:18:51] dberkholz: thank you for chairing [21:19:03] thanks everyone! [21:19:09] ta ta [21:19:13] thanks ulm for prodding on notifications =)