path: root/meeting-logs/20110809.txt

19:00 < dberkholz@> for grobian, i'm gonna keep things simple and just try keeping an updated summary here: http://dev.gentoo.org/~dberkholz/20110809_summary.txt =)
19:00 < dberkholz@> alright, i've got 1900. who's here?
19:00 <   grobian@> dberkholz: weird, so you preselect what we can vote on
19:00  * hwoarang here
19:00 <       ulm@> here
19:00 <   grobian@> here
19:01  * Chainsaw is present
19:01 < dberkholz@> Betelgeuse, jmbsvicetto: around?
19:01 < dberkholz@> grobian: i presented two proposals, and i didn't see anyone present a third one...
19:02 <   grobian@> but me
19:02 <  hwoarang@> could you hold one until the rest are here? :)
19:02 <  hwoarang@> and we have another item before that :)
19:03 < dberkholz@> yeah, we're not doing anything but clarifying/discussing the agenda
19:04 <  hwoarang@> should we call them? :)
19:04 < dberkholz@> if you feel like it, go ahead. they've only got a minute to show up, so you'd better be quick =D
19:04 <Betelgeuse@> dberkholz: yes
19:04 <  Chainsaw@> jmbsvicetto has always been lenient with us.
19:04 <  Chainsaw@> Can we give him a call please?
19:05 <  hwoarang@> i will call him
19:05 <jmbsvicett@> here
19:05 <  hwoarang@> ah
19:05 <  Chainsaw@> Thank you hwoarang.
19:05 < dberkholz@> if someone's got his number handy, go ahead. let's get the meeting rolling..
19:05 < dberkholz@> oh, good.
19:05 <  Chainsaw@> Excellent. We are complete.
19:05 <  hwoarang@> jmbsvicetto: too bad I would like to hear your voice :p
19:05 <   grobian@> hmmm, Betelgeuse, jmbsvicetto come on
19:06 < dberkholz@> they're both here now, we're set
19:06 < dberkholz@> so, let's get started right off with the first topic, advance notice for meetings
19:06 <jmbsvicett@> hwoarang: hehe
19:06 <jmbsvicett@> I'll call Betelgeuse
19:06 < dberkholz@> 19:04 <Betelgeuse@> dberkholz: yes
19:06 <jmbsvicett@> right, sorry
19:06 <Betelgeuse@> grobian: ?
19:07 <   grobian@> Betelgeuse: sorry, huge lag here
19:07 <   grobian@> didn't see you're around
19:07 <  Chainsaw@> Yes, I was the one that suggested 48 hours might be enough.
19:07 < dberkholz@> any reason we shouldn't vote on the 7-day vs 2-day advance notice?
19:07 <  Chainsaw@> As opposed to a week.
19:07 <   grobian@> voting is fine with me
19:07 <jmbsvicett@> what are we voting on?
19:07 <jmbsvicett@> The advance notice or the agenda posting?
19:07 <  hwoarang@> yes
19:08 < dberkholz@> first subpart is advance notice in general, advance agenda's the next bit if needed
19:08 <jmbsvicett@> my argument has always been that we need 1 week advance notice, not that the agenda needs to be define with that 1 week notice
19:08 <  hwoarang@> i second that
19:08 <Betelgeuse@> dberkholz: And what happens if the deadline is missed?
19:09 <  hwoarang@> jmbsvicetto: 1 week advance notice is good but you need to give to the community a draft of the upcoming agenda too
19:09 < dberkholz@> ok, let's vote then: should a 1-week notice be required for a meeting?
19:09 <   grobian@> hwoarang: +1
19:09 <jmbsvicett@> yes
19:09 <   grobian@> yes
19:09 <       ulm@> yes
19:09 <  hwoarang@> yes
19:09 <  Chainsaw@> Okay.
19:09 <  Chainsaw@> yes
19:09 < dberkholz@> that's a majority, then.
19:09 <  Chainsaw@> I am swayed, this one won't make it.
19:09 <jmbsvicett@> Betelgeuse / dberkholz: your vote?
19:10 < dberkholz@> irrelevant, but no
19:10 <  hwoarang@> we still to answer Betelgeuse's question
19:11 <  hwoarang@> slacker point for chairman?
19:11 < dberkholz@> i don't think we need to deal with that unless it becomes an ongoing problem
19:11 <jmbsvicett@> hwoarang: in my view, the 1 week notice is an approximate advanced notice. So if we miss it for a day or so, it isn't an obstacle.
19:11 <Betelgeuse@> Yes I think we should aim to send things well in advance.
19:11 <   grobian@> I do prefer a draft agenda by that time
19:11 <  hwoarang@> jmbsvicetto: err why did we vote then if it is not a hard requirement?
19:12 <  hwoarang@> i believe we need a draft of the agenda 1 week before
19:12 < dberkholz@> on that note, let's move on to the 2nd part of this topic, the agenda notice
19:12 <Betelgeuse@> We don't necessarily need to send things in stone.
19:12 <Betelgeuse@> s/send/set/
19:12 <  hwoarang@> sure
19:12 <jmbsvicett@> hwoarang: because we should attempt to do it like that?
19:12 < dberkholz@> anyone got a problem with voting on whether agendas must also be sent 1 week in advance?
19:13 <  hwoarang@> jmbsvicetto: if the requirement is not hard, people will dont pay attention. I can easily imagine a 24-48 delay window
19:13 <   grobian@> dberkholz: no problem
19:13 <jmbsvicett@> dberkholz: no, move on
19:13 <  hwoarang@> i would change that to s/agendas/proposed &/
19:13 <  hwoarang@> or draft, whatever
19:14 <Betelgeuse@> s/must/should/ unless we want to deal with what happens if it's not sent
19:14 < dberkholz@> ok, let's vote: should draft agendas be sent 1 week in advance (as opposed to 48 hours)?
19:14 <  hwoarang@> yes
19:14 <   grobian@> yes
19:14 <       ulm@> yes
19:15 < dberkholz@> no, again
19:15 <jmbsvicett@> yes (they may be empty if there's nothing in the list at that point)
19:15 <  hwoarang@> on that note, discussion about the upcoming agenda should probably start 2 weeks before the meeting.
19:15 <jmbsvicett@> and the mail should ask people to present issues to be discussed
19:15 <   grobian@> agreed
19:15 <  hwoarang@> jmbsvicetto: if agenda is empty, 1 week is too short to collect ideas
19:15 <       ulm@> jmbsvicetto: good point
19:16 <jmbsvicett@> I'm fine with 1 week for that
19:16 <Betelgeuse@> sending what's currently on the table is fine
19:16 <jmbsvicett@> hwoarang: I don't think that was a problem last year (starting the discussion 1 week before the meeting)
19:16 < dberkholz@> any other decisions need to be made on that topic?
19:17 <  hwoarang@> fair enough
19:17 < dberkholz@> i'd like to move on to the changelog autogeneration
19:17 <  Chainsaw@> Wow. Lag burst.
19:17 <  Chainsaw@> Sorry if you were waiting on me for anything.
19:18 < dberkholz@> first off, it's worth reminding everyone that the last council voted to autogenerate changelogs from commit messages
19:18 < dberkholz@> i put up 2 more specific proposals to vote on; are there others that should be included?
19:18 <   grobian@> I think it's not complete
19:18 <jmbsvicett@> dberkholz: You've dropped from the possible votes, having the changelogs completely autogenerated from commit messages, correct? I read your proposal as suggesting only appending to existing files
19:19 < dberkholz@> i didn't see it as an option that enough of us supported to put on the list, but if that's wrong then tell me
19:19 <jmbsvicett@> That's one of the issues grobian raised in the ml before
19:19 < dberkholz@> are there at least a couple of you that want to vote for that?
19:19 <       ulm@> dberkholz: I think we need a possibility to retroactively change existing entries
19:19 <       ulm@> otherwise it's going to be a mess
19:19 <Betelgeuse@> dberkholz: I don't think we should have any kind of prefiltering for options
19:19 <jmbsvicett@> I'm just trying to confirm I didn't lost anything. I'm ok with appending information to the existing files
19:20 < dberkholz@> alright, let's simplify this into a couple of separate votes then
19:20 <   grobian@> dberkholz: why not follow my initial three questions?
19:20 <   grobian@> - should all commit message be included
19:20 <   grobian@> - should commit messages be appended to/updated?
19:20 <   grobian@> - should existing information in ChangeLog files be retained?
19:21 < dberkholz@> i don't understand the 2nd one and how it's different from the 3rd one
19:21 <   grobian@> modify a message vs keep the ChangeLog files that are in CVS now
19:21 <jmbsvicett@> grobian: your 2nd question seems to be tied to the git notes proposal
19:21 <   grobian@> you can just edit a ChangeLog file, but if it's generated, you need to change the commit message
19:22 <   grobian@> jmbsvicetto: yes, that came out of that
19:23 <jmbsvicett@> One question not directly related to ChangeLogs but that is tied to the whole discussion, assuming we move to git, do we expect users to continue using rsync or move to git?
19:23 < dberkholz@> that's so far OT for this discussion
19:23 <  hwoarang@> yes
19:23 <   grobian@> you mean, should ChangeLogs be in the tree committed somehow?
19:23 < dberkholz@> git-scm list is the place for that
19:23 <jmbsvicett@> The point is that the whole debate about whether commit messages should be in rsync or in the scm is null if users are supposed to keep using rsync
19:23 <  hwoarang@> we should find a solution without having git in mind
19:23 <bonsaikitt > I would assume that at least initially users will continue with rsync
19:24 <  Chainsaw@> hwoarang: Agreed, it will make the git migration easier if we get this in place on CVS first.
19:24 <   grobian@> but I agree it goes OT on the subject mostly
19:24 <  hwoarang@> git may take ages
19:24 <jmbsvicett@> dberkholz: The question is tied to the above: do we expect users to have access to the scm commit messages or not
19:24 <   grobian@> Chainsaw: I implemented it last week for Prefix, all ChangeLogs are generated in the Prefix rsync tree
19:24 < dberkholz@> we're using CVS today, and they don't, and we're voting on stuff we can do today
19:24 <  hwoarang@> jmbsvicetto: i think users will still need rsync
19:24 < dberkholz@> so the answer must be no
19:25 < dberkholz@> git's been floating around for 5 years now, we can't make decisions that depend on it happening soon
19:25 <  hwoarang@> exactly
19:25 <jmbsvicett@> yes, I agree with that
19:25 <       ulm@> users will need things like ${PORTDIR}/metadata and it's not clear how to handle that in git
19:25 < dberkholz@> let's try to get back to the changelog topic here
19:25 <jmbsvicett@> but a large part of the discussion on ChangeLogs, has git in the background
19:26 <  hwoarang@> which is wrong :)
19:26 <jmbsvicett@> I'm not arguing otherwise
19:26 <   grobian@> jmbsvicetto: my intention was to separate it, so the functional requirements can be put on the table
19:26 <jmbsvicett@> ok, so let's get back to changelogs
19:26 < dberkholz@> let's return to grobian's initial questions and vote on the first one
19:26 <   grobian@> hence my three questions largely dealing with policies
19:26 < dberkholz@> should we allow filtering of which commit messages show up in changelogs?
19:26 <   grobian@> no
19:27 <       ulm@> yes
19:27 <  hwoarang@> yes
19:27 <Betelgeuse@> no
19:27 <jmbsvicett@> no (I keep the vote from previous council)
19:27 < dberkholz@> yes
19:27 <  Chainsaw@> no
19:27 < dberkholz@> good, that's settled.
19:28 < dberkholz@> no filtering
19:28 < dberkholz@> now let's vote on his third question, since that's pretty easy to figure out too: should we overwrite old changelog entries with commit messages or retain that information?
19:29 <jmbsvicett@> dberkholz: let's vote on the 2nd as I have a suggestion to split the 3rd in 2 questions
19:29 < dberkholz@> ok, hold on.
19:29 < dberkholz@> what's your suggestion?
19:29 <   grobian@> does everybody understand the 2nd question?
19:29 <       ulm@> no
19:29 <   grobian@> I may have not made myself clear
19:29 <       ulm@> please clarify
19:29 < dberkholz@> it seems like you want a backing store for changelog messages in addition to the commit message
19:29 <   grobian@> ok, consider the ChangeLog of today
19:29 <   grobian@> if you have a typo, or forgot a bugreference
19:29 < dberkholz@> so there's still a place to edit
19:29 <jmbsvicett@> 3. Should we try to retain information from old ChangeLogs? 4. Should we allow to cut-off / implement an automatic rule to cut-off large / old ChangeLogs?
19:29 <   grobian@> you just edit the ChangeLog
19:30 < dberkholz@> seems like QA or a repoman rule can take care of part 4 there
19:30 <jmbsvicett@> dberkholz: it's a policy issue, in my view
19:30 <   grobian@> jmbsvicetto: that has nothing to do with old ChangeLog information to me
19:31 <   grobian@> ulm: if you generate a changelog from commit messages, you cannot just add that bugref by editing the commit message or something
19:31 < dberkholz@> it doesn't really have pertinence to this specific topic of autogeneration, since the information's there regardless
19:31 <jmbsvicett@> grobian: with your proposal, we either start with empty changelogs for all packages and append as people commit to the packages or we start with the current changelog content and append to it
19:31 <       ulm@> grobian: yeah, I think I understand it now ;)
19:31 <   grobian@> jmbsvicetto: no, see the prefix tree
19:31 <       ulm@> and there's nothing worse than a misspelled user name in credits ;)
19:31 <   grobian@> jmbsvicetto: http://rsync1.prefix.freens.org/app-admin/chrpath/ChangeLog
19:31 <   grobian@> that's not empty
19:32 <   grobian@> jmbsvicetto: but completely generated
19:32 < dberkholz@> it's generated from historic cvs commit messages, not empty
19:32 <   grobian@> ulm: that's nasty, yes
19:32 <jmbsvicett@> grobian: right, that's the 2nd option: you use what exists already - in this case instead of appending to the current file you generate it automatically from commit messages
19:33 < dberkholz@> maybe you need an AUTHORS file or header info for that kind of information
19:33 <   grobian@> jmbsvicetto: no, this comes from cvs log, not from ChangeLog
19:33 <   grobian@> jmbsvicetto: as I showed in my original mail, sometimes there is a difference in content here
19:33 <jmbsvicett@> grobian: yes, I understand
19:33 <   grobian@> jmbsvicetto: question 3 is exactly about that
19:33 <jmbsvicett@> grobian: what I meant was that you could either start from 0 or use existing information. When reusing what exists, there are 2 options: append to current files or regenerate them
19:33 <   grobian@> jmbsvicetto: do we care about the different content so much that we need to do complicated stuff to retain the content of the ChanegLog files
19:34 <       ulm@> grobian: yes
19:34 < dberkholz@> i don't know why we would start from zero, that option never even occurred to me
19:34 <jmbsvicett@> ok, then let's keep your 3rd and answer to my 4th as well
19:34 <   grobian@> starting from 0 seems like a non-option to me
19:34 <Betelgeuse@> Should we move the discussion back to ml?
19:34 <jmbsvicett@> It's a theoretical option. I don't support it
19:34 <Betelgeuse@> Seems like people are still in the discussion step
19:35 <   grobian@> if it isn't clear enough what we're voting on, we're forced to yes
19:35 <jmbsvicett@> we might want to discuss a bit more about the remaining 3 questions
19:35 <   grobian@> do we think we know what we're talking about?
19:35 <jmbsvicett@> grobian: yes
19:35 <   grobian@> jmbsvicetto: do you think 2 is isolated enough?
19:35 <jmbsvicett@> yes
19:35 < dberkholz@> http://dev.gentoo.org/~dberkholz/20110809_summary.txt
19:35 <   grobian@> can we vote on it then?
19:36 < dberkholz@> i've put my understanding of our votes there
19:36 <jmbsvicett@> grobian: if I may, "Should ChangeLog remain an editable file or should it become a file supporting only append mode?"
19:36 < dberkholz@> i'm totally fine with voting on both of them right now
19:36 <   grobian@> jmbsvicetto: then you'll have to bring back discussion to -dev
19:36 <   grobian@> or -project
19:36 <   grobian@> or whatever
19:37 <  hwoarang@> i dont understand what is the problem with typos
19:37 <   grobian@> because that's a unconsidered option
19:37 <  hwoarang@> ah ok sorry
19:37 < dberkholz@> they can't be fixed if they come from commit messages, and some of us really don't want to live with them forever
19:37 <  hwoarang@> yes my mistake
19:37 <   grobian@> jmbsvicetto: my vision is that it should disappear as file
19:37 <jmbsvicett@> grobian: that is exactly what you want us to vote, right?
19:37 <   grobian@> jmbsvicetto: purely virtual
19:38 <  hwoarang@> i am fine to vote for these items too btw
19:38 <   grobian@> I assumed a "generated changelog", is the way to go
19:38 <jmbsvicett@> ok, let's replace file with medium. Is that better?
19:38 < dberkholz@> ok, who's not ready to vote on whether we should overwrite or retain existing info?
19:39 <   grobian@> s/info/ChangeLog/
19:39 < dberkholz@> sure. existing changelog messages
19:39 <       ulm@> dberkholz: by "existing info" you mean current contents of ChangeLog files?
19:39 < dberkholz@> yep, thanks for asking
19:39 <   grobian@> ready for voting on that here
19:40 <jmbsvicett@> dberkholz / grobian: Sorry, are we voting for 2 or 3? 2 = immutable + append vs free edition, 3 = can we autogenerate info or do we need to retain 100% complaince with existing changelogs?
19:40 <   grobian@> seems 3 to me
19:40 < dberkholz@> here's the vote: do we overwrite existing changelog messages from cvs logs, or retain existing changelogs and only append new commit messages?
19:41 < dberkholz@> just say "yes" for overwrite
19:41 <jmbsvicett@> dberkholz: you've put the 2 questions together
19:41 <   grobian@> overwrite
19:41 <  Chainsaw@> append
19:41 <       ulm@> retain existing changelogs
19:41 <  hwoarang@> retain
19:42 < dberkholz@> retain/append for me too
19:42 <  Chainsaw@> (4 retain, 1 overwrite so far)
19:42 <jmbsvicett@> I'd prefer append to existing files
19:42 <   grobian@> ok, interesting
19:42 < dberkholz@> good, that's 2 out of 3. the most complex is last, and i'm wondering whether we should discuss it more on lists
19:43 <Betelgeuse@> retain is ok but if it delays the implementation I am fine with overwriting
19:43 <   grobian@> think so
19:43 <   grobian@> because people want to retain, the ChangeLog file probably remains existing, so editing is easy
19:43 <   grobian@> which makes 2 a moot point
19:43 <Betelgeuse@> The question might become moot any way if we start restricting the timespan.
19:43 <   grobian@> Betelgeuse: in that case the retain of previous vote is, strange
19:44 <  Chainsaw@> jmbsvicetto? Betelgeuse?
19:44 <jmbsvicett@> Betelgeuse: you mean allowing to cut-off the files?
19:44 <   grobian@> because all cases it actually makes sense to retain are in the far past
19:44 <   grobian@> the rest is all echangelog + repoman commit
19:44 <jmbsvicett@> grobian: from the complaints, I'd expect that to be true for ~99% of the cases
19:44 <Betelgeuse@> grobian: I am not really sure if everyone does that
19:44 <  Chainsaw@> I am lagged again, aren't I. So sorry.
19:45 <   grobian@> jmbsvicetto: apart from removes, ok, but you just voted for all commits to be included
19:45 <   grobian@> no filtering
19:45 < dberkholz@> we might need to discuss that again whenever a git migration is close to figure out whether that changes things, but it can wait
19:46 <jmbsvicett@> grobian: I voted for adding all messages to changelogs, but I'm open to a discussion if it should be possible to cut-off the files - cut-off old entries
19:46 <   grobian@> let's move on, this is confusing enough in itself
19:46 <   grobian@> jmbsvicetto: yes, of course, and so I do
19:46 <   grobian@> jmbsvicetto: if you assume the first, the 3rd is sort of edge case
19:46 < dberkholz@> yeah, let's try to get through the other couple of topics.
19:46 <   grobian@> anyway, let's move on, we'll discuss on ML
19:46 <Betelgeuse@> grobian: As long as we keep the ancient history I would prefer the existing entries over the cvs commit messages
19:47 <   grobian@> Betelgeuse: cvs is retaining history, I hope git does that too
19:47 <  hwoarang@> it is not clear to me whether we have a final solution or not
19:47 <jmbsvicett@> grobian: it does
19:47 <   grobian@> Betelgeuse: if it doesn't, I wouldn't put my hopes on it
19:47 <   grobian@> hwoarang: no
19:47 < dberkholz@> we have a solution to 2/3 of the questions, the other one should get discussed on the list
19:47 <jmbsvicett@> hwoarang: the discussion will continue in the ml
19:47 <  hwoarang@> ok
19:47 < dberkholz@> the next topic is IRC cloaks for contributors, users, etc.
19:48 < dberkholz@> there seemed to be some interest on -project to delegate this to devrel and userrel to work out as they see fit
19:48 <jmbsvicett@> dberkholz: about that, one thing that might not be clear to everyone is that cloaks are handled by the freenode group contacts
19:48 <   grobian@> jmbsvicetto: I recall you weren't to happy about the vote question, is that still the case for you?
19:48 <       ulm@> jmbsvicetto: please remind me, who's our group contact currently?
19:49 <Betelgeuse@> ulm:  I am
19:49 <jmbsvicett@> The current group contacts were related to devrel, undertakers and userrel, but that isn't a requirement
19:49 <jmbsvicett@> Betelgeuse is our primary group contact. The rest are me, Calchan and rane
19:49 <jmbsvicett@> grobian: for the cloaks? I'm not against the vote, I'd just like people to clarify what we'd be voting on
19:50 < dberkholz@> the vote is that it is not a council issue
19:50 <  hwoarang@> i think there are 2 questions here
19:50 <  hwoarang@> 1) do we want them? 2) if yes, who will manage them
19:50 <   grobian@> jmbsvicetto: and I'd appreciate knowing that
19:50 <  Chainsaw@> dberkholz: I note that I have failed to opt into the meeting chair list. Can I host the september one?
19:50 <  Chainsaw@> Okay, all in favour of giving out user/contributor cloaks?
19:51  * Chainsaw raises hand
19:51 < dberkholz@> i still don't think it's a council issue and i would like to vote to delegate this to devrel and userrel
19:51 <jmbsvicett@> Chainsaw: we already do contributor -> ATs/HTs
19:51 < dberkholz@> regardless of how i personally feel about it
19:52 <jmbsvicett@> dberkholz: I also don't think this needs to be handled at the council level
19:52 < dberkholz@> assigning people more work isn't really my favorite thing to do =)
19:52 <   grobian@> dberkholz: agree on that
19:52 <  hwoarang@> dberkholz: whether we want them or not is a project issue. then we can delegate it to devrel
19:52 <jmbsvicett@> but I understand tampakrap and hwoarang's wish to have a global policy about it
19:52 <jmbsvicett@> and support it
19:52 <   grobian@> let them present a policy first?
19:52 <   Calchan > in case you're interested in the opinion of this group contact, please make sure that whatever you decide is OK with those that are going to deal with it
19:52 <  hwoarang@> the policy is to grant a user/* cloak on developer's request
19:52 <jmbsvicett@> I think that's the best course of action
19:53 <   Calchan > hwoarang, no
19:53 < dberkholz@> i would like to propose a vote to delegate this to devrel and userrel
19:53 <   grobian@> ok, Calchan are you ok with discussing and chiming in on ML?
19:53 <   Calchan > hwoarang, we don't grant user cloaks atm
19:53 < dberkholz@> both the decision and the action
19:53 <  hwoarang@> Calchan: this is why council's vote is required
19:53 <  hwoarang@> to decide if user's cloak should be back in the game
19:53 <  hwoarang@> do we want them as Gentoo project?
19:53 <jmbsvicett@> hwoarang: I don't think it needs a council vote
19:54 < dberkholz@> so, after repeating myself 3 times, maybe i should be more clear
19:54 <  hwoarang@> i thought it was a global issue
19:54 <jmbsvicett@> hwoarang: we can have global discussions that reach an agreement without council intervention
19:54 <  hwoarang@> ok
19:54 <   Calchan > hwoarang, are you seriously going to force group contacts to act against their will? if not, why don't you let them decide
19:54 <Betelgeuse@> dberkholz: just start collecting votes :)
19:54 < dberkholz@> vote: should devrel and userrel determine how and whether to give contributor and user cloaks?
19:54 < dberkholz@> yes.
19:54 <  hwoarang@> dberkholz: accoring to Calchan this is not a devrel, userrel issue
19:55 <  hwoarang@> more likely a gentoo-groupcontacts issue
19:55 <       ulm@> no
19:55 <   grobian@> dberkholz: no vote at all, it's not clear, and not an issue for council
19:55 <   Calchan > hwoarang, I have never said that, and now I shut up :o/
19:55 <Betelgeuse@> hwoarang: currently devrel runs group contacts
19:55 < dberkholz@> considering the group contacts are all devrel and userrel, and if they aren't currently then they should be, i still do consider it under their umbrella(s)
19:55 <  hwoarang@> ok
19:56 <Betelgeuse@> Calchan: Really Group Contacts shouldn't be able to veto but certainly their opinions should be listened to. In this case as I am both in the council and devrel the question is theoretical.
19:56 <jmbsvicett@> dberkholz: let me repeat myself, that the current group contacts were at the time and still are devrel, undertakers and userrel was a coincidence
19:56 <  hwoarang@> Calchan: you said that I am trying to force group contacts to act against their will
19:56 < dberkholz@> i've gotten 1 yes from me, 1 no from ulm, and nothing else from anyone
19:56 <jmbsvicett@> dberkholz: to be clear, it's up to the current group contacts and freenode to chose the group contacts (per informal policy, whim or however you want to call it)
19:56 < dberkholz@> so why are even discussing this if we aren't making any decisions?
19:56 <jmbsvicett@> dberkholz: meaning that there's no gentoo policy on this and there's limited influence
19:57 <Betelgeuse@> dberkholz: I will vote blank as I am too involved on either side any way
19:57 <jmbsvicett@> dberkholz: make it a devrel + userel decision - no
19:57 <jmbsvicett@> dberkholz: move it to the mls so that the community can reach an agreement - yes
19:57 <  hwoarang@> we already had a discussion
19:57 <       ulm@> right, let's have interested parties present a policy and then we can vote on it
19:57 <  hwoarang@> why do we need to wait 30 more days
19:57 <   grobian@> sounds like a plan
19:57 < dberkholz@> if the community had reached an agreement, we wouldn't be screwing around here discussing it still
19:57 <  hwoarang@> sigh
19:58 < dberkholz@> alright, i'm done with this topic
19:58 <  hwoarang@> dberkholz: Betelgeuse said that this could be part of devrel GLEP proposal
19:58 < dberkholz@> we're not getting anywhere with it
19:58 < dberkholz@> anyone else?
19:58 <   grobian@> next topic
19:58 <       ulm@> dberkholz: move on
19:58 <   grobian@> easy vote
19:58 <jmbsvicett@> move one
19:58 <jmbsvicett@> on*
19:59 < dberkholz@> ok, the -council list
19:59 < dberkholz@> do we need it to discuss agenda items, in addition to -dev, -project, and the council alias for procedural stuff?
19:59 <Betelgeuse@> no
19:59 <jmbsvicett@> no
19:59 <       ulm@> yes
19:59 <   grobian@> yes
20:00 <Betelgeuse@> If it's reopened someone needs to draft guidelines on when to post there.
20:00 <  Chainsaw@> yes
20:00 <  hwoarang@> no
20:00 < dberkholz@> no
20:00 <  Chainsaw@> Tie-breaker?
20:00 <  Chainsaw@> -project it is.
20:00 <   grobian@> 4 no, 3 yes, right?
20:00 <Betelgeuse@> yes
20:01 <  Chainsaw@> Indeed. We lose. Sorry grobian.
20:01 <Betelgeuse@> Chainsaw: For me it's ok if you want to take next meeting
20:01 <   grobian@> that's the game
20:01 < dberkholz@> alright, i have a current chair schedule
20:01 <   grobian@> dberkholz: so action point, that bug should be updated, and people poked to close that list down
20:01 < dberkholz@> anyone got a problem with it?
20:02 <jmbsvicett@> dberkholz: I'm ok with it
20:02 <  Chainsaw@> dberkholz: I would like to be on it, but other then that it looks good :)
20:02 < dberkholz@> Chainsaw: reload
20:02 < dberkholz@> if you want to be on it again, find another volunteer =)
20:02 <jmbsvicett@> If you want to adjust it still, we should pick the next month's chair and have a vote in the mls for a (the?) final proposal
20:02 <  Chainsaw@> dberkholz: Thumbs up.
20:03 <  Chainsaw@> jmbsvicetto: Outdated comment. Happy with it now.
20:03 <  hwoarang@> dberkholz: please keep this list on your devspace
20:03 <jmbsvicett@> ok
20:03 < dberkholz@> alright, i'm going to put that into a table on the council page
20:03 <   grobian@> jmbsvicetto: hmmm, I cannot guarantee my agenda now, I would like to allow for individual arrangements amongst council members
20:03 < dberkholz@> and if anyone wants to trade, feel free
20:03 <jmbsvicett@> yeah, please move it to the council web space
20:04 <jmbsvicett@> grobian: sure, there's no problem with that
20:04 <   grobian@> jmbsvicetto: ok
20:04 <jmbsvicett@> but whenever someone does an arrangement, that person has to update the file
20:04 <   grobian@> sounds fair
20:05 < dberkholz@> anything else we need to get through today?
20:05 <  hwoarang@> should we update the council page
20:05 <  hwoarang@> section 4
20:05 <jmbsvicett@> hwoarang: we can add a link there
20:06 < dberkholz@> sure, i'll do that to describe the chair selection while i'm doing the table
20:06 <jmbsvicett@> dberkholz: not from me
20:06 <  hwoarang@> Also the meeting date is the second Tuesday
20:06 <  hwoarang@> not monday
20:06 < dberkholz@> anyone got an open-floor item besides the 2 that are explicitly not on the agenda? =D
20:07 <jmbsvicett@> For the log, the next meeting will be held on Tuesday 20110913 1900 UTC
20:07 < dberkholz@> great, that wraps things up for today. thanks everyone