[21:10:12] <dilfridge> 1) Roll call
[21:10:12] -*- WilliamH is here, late, sorry about that
[21:10:23] -*- blueness here
[21:10:27] -*- dilfridge here
[21:10:27] -*- rich0 here
[21:10:27] -*- scarabeus here
[21:10:31] <dberkholz> cool, that's everyone
[21:10:34] -*- ulm here
[21:10:43] <dilfridge> good
[21:10:54] <dilfridge> then we immediately go to point 2)
[21:11:08] <dilfridge> 2) Resume discussion on the new Code of Conduct [2-5]
[21:11:25] <dilfridge> this is worded a bit vague
[21:11:37] <dilfridge> maybe one first question would be
[21:11:49] <dilfridge> (since this came up in the mailing list discussion)
[21:12:01] <dilfridge> do we want to modify the existing CoC at all?
[21:12:49] <scarabeus> i do, and seems markos as the tl of the project wants...
[21:12:58] <dberkholz> i think the new one is useful. it has a more positive tone and provides some more explanation of the basic ideas.
[21:13:03] <rich0> I already posted on the list, but I think the principles of the CoC don't really need changing.  I'm all ears if somebody has something specific they want to take issue with, but I don't see the point a full rewrite.
[21:13:14] <ulm> it should be slightly updated to account for changes that happened in the meantime
[21:13:22] <ulm> but not rewritten from scratch
[21:13:25] <dberkholz> the basic ideas are the same, but it drops some of the technical stuff that's not really pertinent.
[21:13:36] <dilfridge> I am personally doubtful whether for example specifying in detail what is offensive is a good idea
[21:13:40] <blueness> i like the new one
[21:13:41] <ulm> all the important things are there in the old text
[21:14:02] <dberkholz> dilfridge: i agree that being complete is impossible and a bad idea, but examples are useful
[21:14:10] <rich0> I just think the new version is pretty verbose.
[21:14:14] <rich0> (and that's coming from me)
[21:14:18] <blueness> i agree with ulm, it basically says the same as the old, but its got a positive spin
[21:14:42] <dberkholz> with the wiki we could fold in the text for each of the points on the new version easily enough
[21:14:59] <dilfridge> ok
[21:15:07] <dilfridge> so in general we have three options
[21:15:38] <dilfridge> 1) leave as is, no changes at all- makes no sense since the technical details are outdated
[21:15:59] <dilfridge> 2) minor revisions, basically updating the old text to new organizational structures
[21:16:19] <dilfridge> 3) major revisions, e.g. according to scarabeus proposal
[21:16:36] <blueness> dilfridge, are we voting?
[21:16:40] <dilfridge> not yet
[21:16:44] <blueness> k
[21:16:55] <blueness> discussion .. i like scarabeus's proposal
[21:17:45] <WilliamH> Can someone link his proposal here again real quick?
[21:17:51] <dberkholz> http://dev.gentooexperimental.org/~scarabeus/gentoo-coc.txt
[21:17:51] <blueness> http://dev.gentooexperimental.org/~scarabeus/gentoo-coc.txt
[21:18:26] <dilfridge> is anyone here in favour of option 1)? if no, we dont even have to put it for a vote
[21:18:55] <rich0> Personally I favor 2.  I'm not opposed to 3, but I think it is a distraction to the issue that people really care about, which is execution.
[21:19:08] <blueness> i'm not in favor of 1
[21:19:24] <dilfridge> ok
[21:20:01] <ulm> I also favour 2, the old CoC would just work if properly enforced
[21:20:03] <rich0> FYI - #3 also needs the #2 treatment as well.
[21:20:20] <dilfridge> I propose to put to a vote:
[21:20:52] <dilfridge> "minor or major revision", minor revision being just updating the wording in the old text to current organizational structures
[21:21:08] -*- dilfridge minor revision
[21:21:13] -*- ulm minor
[21:21:32] -*- scarabeus likes mine obviously
[21:21:46] -*- WilliamH minor revision; the only difference between old and new really is verbosity and examples...
[21:21:53] -*- rich0 minor
[21:21:58] -*- blueness likes scarabeus 
[21:22:12] <dberkholz> i like scarabeus. and his CoC.
[21:22:15] <WilliamH> Maybe we could encorporate some of the new points as part of the minor revision...
[21:22:38] <dilfridge> that's four minor, three major
[21:22:44] <hwoarang> having examples and verbosity is good in a multicultural and multilingual environment
[21:22:47] <dberkholz> if we do some of scarabeus' changes in the form of a diff to the existing one, perhaps that would seem more minor.
[21:22:47] -*- hwoarang shuts up
[21:22:55] <WilliamH> I'm not opposed to using some of scarabeus' changes
[21:23:21] <ulm> sure, some of the new wording could be incorporated
[21:23:26] <rich0> agree
[21:23:28] -*- WilliamH agrees with dberkholz 
[21:23:34] <dilfridge> fine
[21:23:40] <rich0> I just want to focus more on what is broken, and starting with the current state makes that more clear.
[21:23:42] <WilliamH> we should encorporate parts of scarabeus  changes...
[21:23:51] <dilfridge> but I suppose we'd have to properly prepare this for the next time
[21:24:40] <dilfridge> my suggestion:
[21:24:43] <WilliamH> sounds good to me. I don't want to shut out what scarabeus  has written, I'm just not sure we need a complete rewrite.
[21:24:54] <dilfridge> a) let's update the old text now as agreed, 
[21:25:16] <dilfridge> b) let's prepare an extended version incorporating part of scarabeus' stuff until next time
[21:25:26] <dilfridge> c) let's then vote on the result
[21:25:53] <WilliamH> Sounds good to me.
[21:26:07] <ulm> fine with me
[21:26:17] <blueness> okay
[21:26:40] <dilfridge> any other opinions?
[21:26:48] <dberkholz> but rewrites fix everything, right? http://www.jwz.org/doc/cadt.html
[21:27:44] <blueness> let's see what the new document looks like and go from there
[21:27:55] <dilfridge> ^^
[21:28:23] <dilfridge> dberkholz: the whole point was not to rewrite but to extend
[21:28:38] <dilfridge> because that was what some people here were saying
[21:29:18] <dilfridge> ok
[21:29:35] <dilfridge> seems like we have said everything we can say today
[21:29:59] <dilfridge> who is doing the work?
[21:32:07] <dberkholz> scarabeus: can you turn your work into a diff against the existing copy?
[21:32:17] <dberkholz> scarabeus: maintaining the general format and the main points of the original?
[21:32:24] <scarabeus> well most probably yep, if next meeting is in omth
[21:32:29] <scarabeus> *month
[21:33:12] <scarabeus> but would be lovely if someone wants to coop as i am not greedy to keep all the work for myself :)
[21:34:39] <dilfridge> ok
[21:34:51] <dilfridge> seems like we dont get any further here.
[21:34:53] <blueness> scarabeus, write something and then email use to review
[21:35:05] <dilfridge> I volunteer to go through the old text and fix the worst outdatedness.
[21:35:42] <dilfridge> yeah scarabeus I guess noone objects if you just send it to the alias somehow
[21:35:45] <dilfridge> ok
[21:35:52] <dilfridge> let's conclude this for now
[21:36:00] <scarabeus> yea use our alias so we all can bikeshed in advance
[21:36:06] <blueness> right!
[21:36:17] <dilfridge> 3. Open bugs with council involvement
[21:36:27] <dilfridge> Bug 477030: Missing summary for 20130611 council meeting [6]
[21:36:29] <willikins> dilfridge: https://bugs.gentoo.org/477030 "Missing summary for 20130611 council meeting"; Doc Other, Project-specific documentation; CONF; ulm:council
[21:36:37] <dilfridge> any news?
[21:36:42] <scarabeus> nope
[21:37:03] <dilfridge> ok same resolution as always, let's annoy petteri
[21:37:10] <dilfridge> Bug 481202: Tracker - Documentation or Implementation Issues for Dropping
[21:37:10] <dilfridge>                of Separate /usr Support [7]
[21:37:11] <willikins> dilfridge: https://bugs.gentoo.org/481202 "Tracker - Documentation or Implementation Issues for Dropping of Separate /usr Support"; Gentoo Linux, Unspecified; CONF; rich0:rich0
[21:37:39] <dilfridge> anything we need to talk about here?
[21:37:51] -*- WilliamH isn't sure of anything either
[21:38:19] <WilliamH> rich0: What is left on that bug?
[21:38:19] <blueness> i thought we agreed that the NFS mounted /usr was not in need of more documentation and that it "just works"
[21:38:28] <dilfridge> actually
[21:38:38] <WilliamH> blueness: yes, we did.
[21:38:40] <dilfridge> since we already decided that the support is there
[21:38:47] <dilfridge> we can probably drop the council from the tracker
[21:38:54] <blueness> i agree
[21:39:17] <dilfridge> ok
[21:39:28] <dilfridge> I'm closing both bugs then now, unless there is protest
[21:39:52] <dilfridge> this concludes point 3
[21:40:01] <dilfridge> 4. Open floor
[21:40:04] <ulm> dilfridge: both bugs?
[21:40:16] <dilfridge> ulm: the tracker and the nfs usr bug
[21:40:25] <ulm> ah
[21:40:37] <ulm> I thought the missing summary one
[21:40:40] <dilfridge> nah
[21:40:44] <dilfridge> that is not fixed :)
[21:41:24] <dilfridge> Open Floor anyone?
[21:41:37] <WilliamH> I have something I've been thinking about... an old policy that maybe we should look at again, but this is just a question not a proposal to change anything...
[21:41:42] <dilfridge> k
[21:41:53] <dilfridge> go ahead
[21:42:32] <WilliamH> I've been thinking about our policy to tell people to use INSTALL_MASK to for example block installation of systemd units, logrotate files, etc, and,
[21:42:49] <blueness> right
[21:43:02] <WilliamH> the conn of that arrangement is that,
[21:43:03] <dilfridge> oh dear
[21:43:15] <WilliamH> if you change your mind, you have to,
[21:43:24] <WilliamH> adjust INSTALL_MASK then
[21:43:30] <WilliamH> emerge -e @world
[21:43:44] <blueness> so?
[21:43:50] <WilliamH> I'm wondering if we put that policy in place before
[21:44:12] <WilliamH> we had --newuse and --changed-use (I don'tknow the exact option for the second one right now), and
[21:44:25] <WilliamH> since we have that it should be re-examined?
[21:44:40] <WilliamH> because now you can
[21:44:48] <ulm> anything that would save significant amounts of space should have a USE flag
[21:44:51] <WilliamH> adjust use flags and only rebuild the affected packages?
[21:44:58] <rich0> The former has been around for a LONG time.  I don't really see the need.  Nobody should bother with INSTALL_MASK unless they have a good reason for it, and if they do, well, they can re-install stuff.
[21:45:06] <dilfridge> well, you'd still rebuild the package then... imagine libreoffice had a systemd unit file 
[21:45:21] <WilliamH> dilfridge: yes, but you wouldn't rebuild the world
[21:45:27] <blueness> rich0, i agree, it works for me because i build embedded systems where every file counts
[21:45:35] <dberkholz> our policy has been to minimize additional use flags when they don't make any meaningful difference in installed size
[21:45:38] <ulm> there's no good reason to use INSTALL_MASK for things like systemd unit files
[21:45:39] <blueness> on my desktop where i use openrc i don't care about systemd unit files
[21:45:42] <ulm> or bash completion
[21:45:43] <dberkholz> the only people doing that stuff should be building embedded systems
[21:45:46] <blueness> so INSTALL_MASK is good enough for me
[21:45:55] <rich0> You wouldn't have to rebuild the world if you didn't mask it in the first place...  makes sense on embedded, but are you just going to switch init systems on an embedded system on a whim?
[21:46:53] <rich0> I don't see INSTALL_MASK as being broken.  It caters to some unusual cases, and for thsoe who want to use it, they can.  It has downsides, like all the alternatives.
[21:46:59] <dilfridge> WilliamH: the question is more, what is the reason for putting something into INSTALL_MASK in the first place? on a desktop system, pure hate for bash completion files for example?
[21:47:17] <dilfridge> I see the point for an embedded system
[21:47:33] <blueness> that's why i brought it up on the list
[21:47:50] <blueness> i already go in and clean stuff out manually, but INSTALL_MASK helps
[21:48:30] <blueness> it might be possible to write a portage helper script which looks for all pachages providing files in INSTALL_HELP
[21:48:36] <blueness> err ... INSTALL_MASK
[21:48:45] <blueness> and then just re-emerges them
[21:48:58] <blueness> i can see how that could be written (using equery as an example)
[21:49:04] <dilfridge> not really, since the files are not recorded then
[21:49:05] <blueness> but i'm not sure how important that is
[21:49:11] <blueness> dilfridge, no?
[21:49:15] <dilfridge> I dont think so
[21:49:21] <WilliamH> blueness: I think that's the thing though, if you mask things out, I don't think they appear in contents at all.
[21:49:30] <blueness> ah
[21:49:45] <dilfridge> but, we could ask zac for that feature (store a list of blocked files in the vdb)
[21:49:52] <blueness> open a bug against portage and give zemdico more work!
[21:50:01] <blueness> :)
[21:50:16] <dilfridge> then such a utility would be easy and you would not have to rebuild world, only the relevant packages
[21:50:31] <dberkholz> in terms of return on effort, i'm just not seeing the value
[21:50:31] <dilfridge> WilliamH: what do you think?
[21:50:45] <blueness> i would just put some marker in vdb's CONTENTS
[21:50:59] <dilfridge> blueness: also possible ("something was blocked")
[21:51:27] <WilliamH> dilfridge: I'm not a portage dev, so I can't really comment on how feasable that is...
[21:51:52] <rich0> dberkholz: ++  Sure, it sounds like a nice feature, but I'd rather zmedico spent the time mowing my lawn as long as we're handing out orders.  :)
[21:52:06] <blueness> WilliamH, grep the portage tree for INSTALL_MASK and go from there, i'm not a portage dev either but that doesn't stop me ;)
[21:52:19] <WilliamH> I wouldn't make it a high priority; I don't use install_mask myself.
[21:52:26] <dilfridge> zac is missing in action a bit, we could always ask Arfrever :)
[21:52:26] <WilliamH> I was just brainstorming really.
[21:52:42] <rich0> is Arfrever good at lawns?
[21:52:44] <WilliamH> dilfridge: heh
[21:53:04] -*- blueness is git pulling portage as we speak
[21:53:25] <blueness> its in here -> bin/misc-functions.sh
[21:53:41] <dilfridge> WilliamH: to be honest, I dont think it's a complex feature to just store a marker "something was blocked by INSTALL_MASK" in the vdb for each package
[21:53:52] <jmbsvicetto> dilfridge: I would prefer you get Zac back
[21:54:22] <jmbsvicetto> dilfridge: There's already enough I'd like him to fix before we break more things
[21:54:31] <dilfridge> no objection
[21:54:48] <blueness> hmm ... it just remove stuff from the image dir before qmerge i think
[21:55:13] <dilfridge> ok but this is technical stuff
[21:55:16] <blueness> actually from ${ED}
[21:55:20] <dilfridge> anything else for the open floor?
[21:56:04] <blueness> done?
[21:56:06] <dilfridge> seems not
[21:56:09] <dilfridge> done
[21:56:12] <dilfridge> meething closed