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 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 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 hwoarang: hehe 19:06 I'll call Betelgeuse 19:06 < dberkholz@> 19:04 dberkholz: yes 19:06 right, sorry 19:06 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 what are we voting on? 19:07 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 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 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 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 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 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 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 We don't necessarily need to send things in stone. 19:12 s/send/set/ 19:12 < hwoarang@> sure 19:12 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 dberkholz: no, move on 19:13 < hwoarang@> i would change that to s/agendas/proposed &/ 19:13 < hwoarang@> or draft, whatever 19:14 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 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 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 I'm fine with 1 week for that 19:16 sending what's currently on the table is fine 19:16 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 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 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 dberkholz: I don't think we should have any kind of prefiltering for options 19:19 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 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 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 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 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 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 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 but a large part of the discussion on ChangeLogs, has git in the background 19:26 < hwoarang@> which is wrong :) 19:26 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 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 no 19:27 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 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 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 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 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 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 grobian: yes, I understand 19:33 < grobian@> jmbsvicetto: question 3 is exactly about that 19:33 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 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 Should we move the discussion back to ml? 19:34 It's a theoretical option. I don't support it 19:34 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 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 grobian: yes 19:35 < grobian@> jmbsvicetto: do you think 2 is isolated enough? 19:35 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 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 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 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 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 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 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 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 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 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 grobian: from the complaints, I'd expect that to be true for ~99% of the cases 19:44 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 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 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 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 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 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 ulm: I am 19:49 The current group contacts were related to devrel, undertakers and userrel, but that isn't a requirement 19:49 Betelgeuse is our primary group contact. The rest are me, Calchan and rane 19:49 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 Chainsaw: we already do contributor -> ATs/HTs 19:51 < dberkholz@> regardless of how i personally feel about it 19:52 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 but I understand tampakrap and hwoarang's wish to have a global policy about it 19:52 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 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 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 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 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 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 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 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 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 dberkholz: meaning that there's no gentoo policy on this and there's limited influence 19:57 dberkholz: I will vote blank as I am too involved on either side any way 19:57 dberkholz: make it a devrel + userel decision - no 19:57 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 move one 19:58 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 no 19:59 no 19:59 < ulm@> yes 19:59 < grobian@> yes 20:00 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 yes 20:01 < Chainsaw@> Indeed. We lose. Sorry grobian. 20:01 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 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 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 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 yeah, please move it to the council web space 20:04 grobian: sure, there's no problem with that 20:04 < grobian@> jmbsvicetto: ok 20:04 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 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 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 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