<14.05.2013 19:00> -!- Betelgeuse changed the topic of #gentoo-council to: Council meeting NOW. Agenda: http://article.gmane.org/gmane.linux.gentoo.project/2462 | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/ <14.05.2013 19:00> * scarabeus eeee <14.05.2013 19:01> <@Betelgeuse> let's start the rollcall <14.05.2013 19:01> <@ulm> here <14.05.2013 19:01> <@grobian> here <14.05.2013 19:01> * scarabeus here <14.05.2013 19:02> -!- mode/#gentoo-council [+v dberkholz] by ChanServ <14.05.2013 19:02> <+dberkholz> back from netsplit-land <14.05.2013 19:03> <@Betelgeuse> so chainsaw only one missing? <14.05.2013 19:03> * WilliamH here <14.05.2013 19:04> <@Betelgeuse> I can text Tony. <14.05.2013 19:04> < scarabeus> maybe he netsplitted too <14.05.2013 19:05> -!- mode/#gentoo-council [+o Chainsaw] by ChanServ <14.05.2013 19:05> <@Betelgeuse> there we go <14.05.2013 19:06> <@Chainsaw> There's always one isn't there. <14.05.2013 19:06> <@Chainsaw> Drinks on me tonight. <14.05.2013 19:06> <@Betelgeuse> Didn't make it to press send on the SMS either. <14.05.2013 19:06> <@Betelgeuse> ok let's start with the agenda then <14.05.2013 19:06> <@Betelgeuse> ulm: the first item is yours <14.05.2013 19:06> <@ulm> clarification of PMS wording <14.05.2013 19:07> <@Betelgeuse> I assume everyone has checked the patch so we can just vote. <14.05.2013 19:07> <@ulm> $@ should go after default args for econf <14.05.2013 19:07> <+dberkholz> can you link to more info for anyone catching up on the logs later <14.05.2013 19:07> <@ulm> http://article.gmane.org/gmane.linux.gentoo.pms/751 <14.05.2013 19:07> <@Chainsaw> The clarification does not seem to introduce a major behaviour change. This is good. <14.05.2013 19:07> <@ulm> plus the rest of that thread <14.05.2013 19:08> < scarabeus> ulm: your proposed patch is fine i dont see any reason why this should be in eapi so I agree with this fix <14.05.2013 19:08> < WilliamH> Tht behaviour always seemed obvious to me. ;-) <14.05.2013 19:08> <@ulm> Chainsaw: it matches portage and paludis behaviour <14.05.2013 19:08> < WilliamH> s/tht/that/ <14.05.2013 19:08> <@Betelgeuse> doesn't hurt to be explicit <14.05.2013 19:08> <@Chainsaw> WilliamH: You can not rely on common sense I am afraid. <14.05.2013 19:08> <@Betelgeuse> ok votes please: <14.05.2013 19:08> <@Betelgeuse> I vote yes <14.05.2013 19:08> * Chainsaw votes yes <14.05.2013 19:08> * ulm votes yes <14.05.2013 19:08> * WilliamH votes yes <14.05.2013 19:08> <@grobian> votes yes <14.05.2013 19:09> <+dberkholz> yes <14.05.2013 19:09> <@Betelgeuse> scarabeus: <14.05.2013 19:09> * scarabeus votes yes <14.05.2013 19:09> <@Betelgeuse> Ok accepted. Next item. <14.05.2013 19:09> <@ulm> pushed to PMS repo: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=31a2d63de1b8914063e82957e41de642d11eb092 <14.05.2013 19:09> <@Chainsaw> Something proper controversial I hope. <14.05.2013 19:09> <@Betelgeuse> seems my link was wrong <14.05.2013 19:09> <@Chainsaw> All this agreeing is boring. <14.05.2013 19:09> < scarabeus> i have 30 seconds lag so dont be suprised a bit by my off replies :-) <14.05.2013 19:10> <@Betelgeuse> though no-one called me on it <14.05.2013 19:10> <@Chainsaw> I concentrated on the ones that did work. <14.05.2013 19:10> <@Betelgeuse> Thread is here http://article.gmane.org/gmane.linux.gentoo.project/2452 <14.05.2013 19:10> <@Betelgeuse> zmedico: are you present? <14.05.2013 19:11> < scarabeus> you don't need zac too much, simply just find out who of us are really not using the preserved-libs feature <14.05.2013 19:12> * scarabeus is for default on as i use it for few years without much fuzz <14.05.2013 19:12> < WilliamH> It is on here with no issues. <14.05.2013 19:12> <@ulm> on here too, though I don't have a string opinion if it should be the default <14.05.2013 19:12> <@Chainsaw> Since it has a potential to save my systems from breakage rather than introduce breakage... <14.05.2013 19:12> <@grobian> there are issues, imo, but it solves more than it causes harm <14.05.2013 19:12> <@Chainsaw> I'd actually be in favour of making that the default. <14.05.2013 19:12> <+dberkholz> i'm for it <14.05.2013 19:13> <@Betelgeuse> We can first decide on if we leave the switching to zac or require it <14.05.2013 19:13> * WilliamH doesn't have a strong opinion on this <14.05.2013 19:13> <@ulm> I see it as zac's decision <14.05.2013 19:14> <@Chainsaw> ulm: Recommendation to enable it, if zac feels it is ready? <14.05.2013 19:14> <@ulm> yeah <14.05.2013 19:14> <@grobian> IMO it's a portage feature, but the question is if we want to formalise it in pms at some point? <14.05.2013 19:14> < WilliamH> Betelgeuse: that's a good point, should we just leave this to zac? <14.05.2013 19:14> <@Chainsaw> ulm: To make it not seem like an edict. <14.05.2013 19:14> <@Chainsaw> WilliamH: Well, he asked for our opinion. <14.05.2013 19:15> <@Betelgeuse> Chainsaw: Which I think is good. <14.05.2013 19:15> <@grobian> do we ever have to rely on this feature from ebuilds or something <14.05.2013 19:15> < WilliamH> Chainsaw: so what if we just tell him we are ok with him enabling it when he feels it is ready? <14.05.2013 19:15> < scarabeus> so yea, lets tell zac to turn it on if he wants <14.05.2013 19:15> <@Chainsaw> WilliamH: That is what I am suggesting. <14.05.2013 19:15> <@Betelgeuse> Chainsaw: Especially as I remember there being something about it going against EAPIs <14.05.2013 19:15> * ulm has no objections against making it the default <14.05.2013 19:15> <@Betelgeuse> But don't count on my memory fully on that :) <14.05.2013 19:15> <@Chainsaw> Betelgeuse: EAPI applies to all package managers, this is a portage-specific default change. <14.05.2013 19:16> <@Chainsaw> Betelgeuse: Seems out of EAPI jurisdiction to me. <14.05.2013 19:16> <@Betelgeuse> Chainsaw: features might not be implemented strictly following EAPI <14.05.2013 19:16> <@Betelgeuse> implementable <14.05.2013 19:16> <@Betelgeuse> Any way lets vote: zmedico can turn on preserve-libs when he so chooses: <14.05.2013 19:16> * WilliamH agrees with chainsaw, this has nothing to do with eapis <14.05.2013 19:16> <@Chainsaw> Betelgeuse: I vote yes. <14.05.2013 19:17> * WilliamH votes yes <14.05.2013 19:17> * grobian votes yes <14.05.2013 19:17> * scarabeus yes <14.05.2013 19:17> * ulm votes yes <14.05.2013 19:18> <@Betelgeuse> dberkholz: <14.05.2013 19:18> <+dberkholz> didn't i already vote? <14.05.2013 19:18> <@Betelgeuse> I didn't see <14.05.2013 19:18> <+dberkholz> i guess i will say it again, i'm for it <14.05.2013 19:18> <@Betelgeuse> yes <14.05.2013 19:18> <@Betelgeuse> ok passed <14.05.2013 19:18> <@Betelgeuse> next item <14.05.2013 19:19> <@Betelgeuse> There was a request for EAPI 6 items <14.05.2013 19:19> <@Betelgeuse> We really only approve final wording <14.05.2013 19:19> <@grobian> yes <14.05.2013 19:19> <@Betelgeuse> ulm: can you give a status update? <14.05.2013 19:20> <+dberkholz> it would be useful to provisionally approve features, so PM implementers don't feel like they're potentially wasting time <14.05.2013 19:20> <@grobian> some of the ideas sound ok, but I don't feel we can do anything on this <14.05.2013 19:20> <@ulm> not really, as I haven't looked into things in detail <14.05.2013 19:20> <@grobian> dberkholz: that's hard if things like the final name of the function are unknown ;) <14.05.2013 19:20> <@ulm> mgorny's initial list seems o.k. <14.05.2013 19:20> <@Betelgeuse> I have my doubts this council will be approving it any way <14.05.2013 19:20> <@ulm> except maybe for #449806 <14.05.2013 19:20> <@Chainsaw> https://bugs.gentoo.org/show_bug.cgi?id=449806 <14.05.2013 19:20> <+dberkholz> i like most of them except for everything related to DOCS and PATCHES. i really see those as legacy of the days before default() made it trivial to modify functions. <14.05.2013 19:21> <@grobian> and 273101 <14.05.2013 19:21> <@Chainsaw> https://bugs.gentoo.org/show_bug.cgi?id=273101 <14.05.2013 19:21> <@ulm> I suggest to create a wiki page for EAPI 6 candidates <14.05.2013 19:21> <+dberkholz> also bug 357561 is pretty tricky <14.05.2013 19:21> <@ulm> as it was useful for EAPI 5 items <14.05.2013 19:21> <@Chainsaw> https://bugs.gentoo.org/show_bug.cgi?id=357561 <14.05.2013 19:21> * grobian agrees <14.05.2013 19:22> <+dberkholz> good call ulm. <14.05.2013 19:22> <@Betelgeuse> wfm <14.05.2013 19:23> <@ulm> ok, make the wiki page an action point <14.05.2013 19:23> <@Chainsaw> Yes, that would be good. And then trawl the wiki each meeting to see if anything looks controversial to a majority of the council? <14.05.2013 19:23> <@Chainsaw> A fixed agenda point, like the bugs with council involvement. <14.05.2013 19:23> <@Chainsaw> That way nobody wastes their time for more than a month. <14.05.2013 19:23> <@ulm> sure, that can be done <14.05.2013 19:25> <@Betelgeuse> anything else? <14.05.2013 19:26> <@ulm> heh, we're ahead of schedule :) <14.05.2013 19:27> <+dberkholz> that's a pleasant change. <14.05.2013 19:27> < scarabeus> does not happen too often :-) <14.05.2013 19:27> <@Betelgeuse> I assume not. <14.05.2013 19:27> <@Betelgeuse> Let's move to open bugs. <14.05.2013 19:27> <@Betelgeuse> I submitted a proposed summary to that one bug <14.05.2013 19:27> <@ulm> https://bugs.gentoo.org/show_bug.cgi?id=457000 <14.05.2013 19:27> <@Betelgeuse> I can't commit it from this machine but I assume someone else here can <14.05.2013 19:27> <@ulm> Betelgeuse: summary lgtm <14.05.2013 19:28> <+dberkholz> k <14.05.2013 19:28> <@Chainsaw> Betelgeuse: Summary looks accurate, thank you. <14.05.2013 19:29> <@Betelgeuse> ulm: can you commit? <14.05.2013 19:29> <@grobian> looks ok <14.05.2013 19:29> <@ulm> Betelgeuse: yes <14.05.2013 19:30> <@ulm> second ... <14.05.2013 19:30> <@Betelgeuse> ok next bug <14.05.2013 19:31> <@Betelgeuse> that seems to be the only one <14.05.2013 19:31> <@Betelgeuse> so I will open the floor for everyone <14.05.2013 19:32> < WilliamH> If I am the only one who is concerned about this, that's cool, but I thought I would ask. <14.05.2013 19:32> <@Chainsaw> Please assemble in an orderly row. The microphone is on. <14.05.2013 19:32> < WilliamH> Am I the only one who is concerned about the reaction on -dev to Markos moving the devmanual repository to github? <14.05.2013 19:32> <@grobian> no <14.05.2013 19:32> <@grobian> I think it should stay on gentoo hardware <14.05.2013 19:32> <@grobian> a mirror is fine <14.05.2013 19:33> * WilliamH is confused about why since we have a lot of packages that have their source trees on github. <14.05.2013 19:33> <@Betelgeuse> upstream != Gentoo <14.05.2013 19:33> <@Betelgeuse> do you mean Gentoo projects? <14.05.2013 19:33> < WilliamH> I'm not sure what the difference is... <14.05.2013 19:34> <@ulm> WilliamH: other upstreams are not bound by our social contract <14.05.2013 19:34> <+dberkholz> our social contract has traditionally been read as gentoo the distribution, not gentoo the project <14.05.2013 19:34> <+dberkholz> we've used proprietary dns providers in the past, for example <14.05.2013 19:35> <@grobian> I fail to see the poitn in that statement <14.05.2013 19:35> <@Betelgeuse> a wrong does not justify another <14.05.2013 19:35> < WilliamH> How do you determin which upstreams are bound by the social contract then? <14.05.2013 19:35> < WilliamH> determine * <14.05.2013 19:36> <@grobian> do you consider the devmanual a document that is leading for Gentoo? <14.05.2013 19:37> <+dberkholz> i would read it as the ones that are required to complete installation according to the gentoo handbook <14.05.2013 19:37> <@ulm> github using non-free software is only one small aspect <14.05.2013 19:37> <@grobian> since we specify policies in the devmanual, I'd find it weird if we'd put that out of our hands <14.05.2013 19:37> <@grobian> we need an authorative copy on our own hardware, imo <14.05.2013 19:38> <@ulm> imho, the bigger issue is that it's a wrong signal if we move important ducumentation from our hardware to third-party servers <14.05.2013 19:38> <@ulm> documentation* <14.05.2013 19:38> <@Betelgeuse> And it's a signal about our distro that we run on Gentoo <14.05.2013 19:38> <@Betelgeuse> So I agree with ulm probably :) <14.05.2013 19:39> <+dberkholz> a signal that we care about building a linux distro and not maintaining a ton of infrastructure? <14.05.2013 19:39> <+dberkholz> s/linux/$OS/ <14.05.2013 19:40> <@grobian> lol <14.05.2013 19:40> < WilliamH> The other thing is, with git, the dependency on a specific repository is really weak. <14.05.2013 19:40> <@grobian> WilliamH: so you mean with CVS that's not the case? <14.05.2013 19:40> < WilliamH> you just do git remote origin set-url foobar <14.05.2013 19:40> < WilliamH> then you are pushing somewhere else. <14.05.2013 19:41> <@grobian> WilliamH: ok, but how does that change what would/should be the authorative location? <14.05.2013 19:41> < WilliamH> grobian: That's the advantage of distributed vcs. every repo has all of the history. <14.05.2013 19:42> < scarabeus> just as note opensuse has everything on github, because it is easiest to attract contributors <14.05.2013 19:42> < scarabeus> even tho it could be hosted <14.05.2013 19:42> <@grobian> WilliamH: I'm trying to understand where VCS supports the argument of moving our own policies to an external repo <14.05.2013 19:42> < scarabeus> so the point in "we don't have server we are not really caring" is quite moot <14.05.2013 19:42> <@grobian> does it mean once we've moved to git, we'll move to github afterwards? <14.05.2013 19:43> < WilliamH> grobian: that's not a relevant question really. <14.05.2013 19:43> < WilliamH> No one is saying that we have to move everything to github <14.05.2013 19:44> <@grobian> I'm trying to understand why we need to move, I thought a DVCS in the first place was easy to keep in many places with full history and so on <14.05.2013 19:44> <@grobian> so we can be on both locations, and have all the benefits, don't we? <14.05.2013 19:45> <+dberkholz> is the idea here that we were about to end early so we're just going to screw around talking about git/github in yet another location? <14.05.2013 19:45> <+dberkholz> if so, why don't we wrap the meeting and you guys can keep going <14.05.2013 19:45> < WilliamH> dberkholz: No, I was just trying to understand why we jumped Markos' case for moving the devmanual to github. <14.05.2013 19:46> < WilliamH> dberkholz: Just a question... <14.05.2013 19:46> <@Betelgeuse> Partly probably because it was not discussed before the move. <14.05.2013 19:47> <+dberkholz> these meetings should be for decisions, not further discussions and clarifications in a new forum on an existing and active mailing-list thread <14.05.2013 19:47> * ulm looks at devmanual history with gitk <14.05.2013 19:47> < WilliamH> dberkholz: Ok, that's fine with me. <14.05.2013 19:47> <@ulm> some pointless merges recently, is that caused by github workflow? <14.05.2013 19:48> <@Betelgeuse> ulm: github makes a merge for fast forwards too <14.05.2013 19:48> <+dberkholz> i'm gonna head out folks. see ya next time <14.05.2013 19:48> <@Betelgeuse> Thanks everyone. <14.05.2013 19:48> <@Betelgeuse> I will close the official part of the meeting now. <14.05.2013 19:48> <@ulm> Betelgeuse: thanks for chairing <14.05.2013 19:48> < WilliamH> Betelgeuse: It shouldn't. No one requires you to use the github web ui. <14.05.2013 19:49> <@Betelgeuse> WilliamH: github != git <14.05.2013 19:49> <@Betelgeuse> WilliamH: github does the merge <14.05.2013 19:49> <@Betelgeuse> WilliamH: and yes you don't have to <14.05.2013 19:49> <@ulm> Betelgeuse: next meeting date? <14.05.2013 19:49> <@ulm> June 11? <14.05.2013 19:49> <@Betelgeuse> ulm: true <14.05.2013 19:49> < WilliamH> Betelgeuse: It doesn't have to; you can use git remotes. <14.05.2013 19:49> < WilliamH> June 11 sounds good to me. <14.05.2013 19:49> <@Betelgeuse> ulm: wfm <14.05.2013 19:50> <@ulm> Betelgeuse: well, you'll be chairing ;) <14.05.2013 19:50> -!- Betelgeuse changed the topic of #gentoo-council to: Next meeting: 2013-06-11 19:00 UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/