path: root/meeting-logs/20130514.txt

<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/