=== encryptz is now known as atoponce === tonyy is now known as tonyyarusso === Varka_ is now known as Varka === tonyy is now known as tonyyarusso === atoponce is now known as encryptz === asac_ is now known as asac [05:56] When is the next meeting to be held? [05:56] @now [05:56] Current time in Etc/UTC: December 07 2007, 05:56:44 - Next meeting: Kubuntu Developers in 5 days [05:56] Palintheus: Ah, thanks [05:56] :) [06:27] moin === Shely is now known as iE18 === \sh_away is now known as \sh === myriam_rs is now known as Mamarok === dholbach_ is now known as dholbach === _czessi is now known as Czessi === Hobbsee_ is now known as Hobbsee === doko__ is now known as doko === \sh is now known as \sh_away === nikolas_ is now known as nikolas === x-spec-t is now known as Spec [20:07] Right. Seems to be consensus that this is now the MOTU meeting, although it doesn't seem to have been scheduled anywhere :) [20:08] No agenda though (https://wiki.ubuntu.com/MOTU/Meetings), so it should be quick. [20:08] maybe we could use an announcement mail for next time (from anyone who remembers the date *g*) [20:08] Any volunteers to take minutes? [20:08] ok [20:08] sistpoty: Good idea. [20:09] Any volunteers to send announcements (1 week before, 1 day before)? [20:09] * DktrKranz offersa [20:09] *offers [20:09] #startmeeting [20:09] Meeting started at 20:09. The chair is sistpoty. [20:09] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [20:09] #action sistpoty takes minutes [20:10] damn, what did I do wrong? [20:10] [ACTION] sistpoty takes minutes [20:10] thanks [20:10] * persia isn't the chair, so please repeat the statement :) [20:10] [ACTION] DktrKranz will send announcement mails [20:10] ACTION received: DktrKranz will send announcement mails [20:10] [ACTION] sistpoty will write minutes [20:10] ACTION received: sistpoty will write minutes [20:11] persia: can I hand over meeting chair to you? *g* [20:11] sistpoty: I don't think so. If you did, I'd post a link to the topic, and call for any other business. [20:11] Errr.. link to the agenda (to MootBot) [20:12] persia: damn... [20:12] Are we having a MOTU meeting? [20:12] ScottK: yes [20:12] ScottK: Trying :) [20:12] Great. [20:12] hi ScottK, hi persia [20:12] Here's the agenda: https://wiki.ubuntu.com/MOTU/Meetings [20:12] hi all :) [20:12] Not very much to discuss, though [20:12] Should be short. [20:13] [LINK]: agenda https://wiki.ubuntu.com/MOTU/Meetings [20:13] LINK received: : agenda https://wiki.ubuntu.com/MOTU/Meetings [20:13] that's a big agenda :) [20:13] ok, any business not on the agenda? *g* [20:13] *agree on date and time of next meeting* [20:13] lol [20:13] Any feedback on using interdiff for upgrades? [20:13] [TOPIC] ScottK: feedback on using interdiff for upgrades [20:13] New Topic: ScottK: feedback on using interdiff for upgrades [20:14] Anyone? [20:14] I've heard a few people complain, and have had a request to find something easier for sponsors. [20:14] * Nafallo didn't know we could :-) [20:14] I had a couple of reviews using interdiff, and I found it of great aid [20:15] persia: Could we script something for interdiff to make it easier? [20:15] oh, we are talking about debdiff stuff :-) [20:15] ScottK: I have a rough script at http://people.ubuntuwire.com/~persia/process-interdiff, but it needs a fair bit of work to be less fragile. [20:16] (also, it calculates the same thing a couple different ways, which is wasteful) [20:16] [LINK]: http://people.ubuntuwire.com/~persia/process-interdiff [20:16] LINK received: : http://people.ubuntuwire.com/~persia/process-interdiff [20:17] persia: Maybe RainCT would work on it. He seems to like that kind of thing. [20:17] Err... That's not a good home: if we stay with interdiff, someone (likely me) needs to fix it, and put it in ubuntu-dev-tools [20:17] ScottK: Good idea. [20:17] Plus he's not here, so he can't object if we assign him an action ;-) [20:17] [IDEA]: RainCT might want to work on interdiff for sponsoring [20:17] IDEA received: : RainCT might want to work on interdiff for sponsoring [20:17] [IDEA]: move the script to ubuntu-dev-tools [20:17] IDEA received: : move the script to ubuntu-dev-tools [20:18] Once it's suitable for general use. [20:18] ok, more feedback to this topic? [20:18] Not from me? [20:18] cjwatson pointed out that the "full interdiff" isn't very interesting, and that the new diff.gz alone might be eaiser. I just haven't tested & evaluated that yet, but I think I agree. [20:20] hi, what is interdiff? [20:21] [LINK] https://wiki.ubuntu.com/UbuntuDevelopment/Interdiff [20:21] LINK received: https://wiki.ubuntu.com/UbuntuDevelopment/Interdiff [20:21] I think what is wanted is diff of the debian dir + diff from the new upstream. [20:22] ScottK: A debdiff gets that, but they need to be evaluated separately. [20:22] Agreed. [20:22] ok, let's move on, shall we? [20:23] Moving on sounds good. I'll propose something else if I can meet all the good points that DktrKranz likes and make it easier for sponsors. [20:23] Are there any MOTUs planning to support these packaging jams that Jono has proposed? [20:23] [TOPIC] supporting packaging jams [20:24] New Topic: supporting packaging jams [20:24] what's that? [20:24] ScottK, I proposed it to our LoCo, we are planning to have a meeting where we'll discuss about it [20:24] * ScottK looks for jono's blog [20:24] I tend to think of Packaging Jams as means to populate PPAs, and not to affect universe directly. [20:25] i thought package jams were like install fests but for packaging [20:25] [LINK] http://www.jonobacon.org/?p=1082 [20:25] http://www.jonobacon.org/?p=1082 [20:25] LINK received: http://www.jonobacon.org/?p=1082 [20:25] Scott's mail is good. Maybe focusing on bugfix (as Debian does) can be more helpful [20:25] Even package updates would be better for us. [20:25] * ScottK is concerned he may be raising expectations urealistically. [20:26] That and focusing on what most MOTUs would view as the wrong problem. [20:26] * sistpoty thinks that it's a great idea, which could make LoCo teams more integrated to MOTU [20:26] ah [20:26] But how many LoCo teams have a local pet MOTU? [20:27] not many i would say [20:27] Hard to say [20:27] where local is the keyword :-) [20:27] ScottK: not many, and I'd hope that this would change [20:27] sistpoty: We've already about 900 packages that are Ubuntu-local, with only about half receiving any maintenance. Can't we push them towards another means of integrating? Is there that much demand to be able to package new software? [20:27] certainly in brazil we do not [20:27] Sweden HAD me, but we were all spread out. [20:27] Packaging Jams don't have to be /new/ software. [20:28] maybe this is more the the city teams? [20:28] s/the/for/ [20:28] jcastro: Ah. That's better then. All the information I'd seen gave that impression. [20:28] I know the one local to me (michigan) covers things like debdiffs and workflow and stuff [20:28] i'm late :( [20:28] Ubuntu Bug Parties? [20:28] persia: imho the goal is not (or should not be) to get new software into ubuntu, but rather to knot the ties between MOTU and LoCos [20:28] "Packaging Jam" is a fine name, as long as it's not all about packaging new software. [20:28] yes, what sistpoty said! [20:28] sistpoty: Then we agree :) [20:29] sistpoty: Reading Jono's blog, I don't think he agrees. [20:29] ScottK: he does, i talked to him a bit on jabber about it, it just wasent clear in the blog [20:29] Did Jono discuss this with anyone before announcing it? [20:29] NEW software is covered by frequent REVU days, so covering unloved packages will be good, especially if we save some bugs for these sessions. [20:30] DktrKranz: REVU only happens 30 weeks a year, which can be frustrating for people uploading the other 22. === neversfelde_ is now known as neversfelde [20:30] ScottK: Jono at least pointed at Michigan as a good example: if the practice there is debdiffs & workflow, I'm not sure it's all bad. [20:31] ScottK: I guess this boils down to the question if new packages should generally be accepted/avoided as means of getting people involved, which I'd rather discuss as a separate topic [20:31] persia: we need to make REVU more dynamic in that it checks $time-of-year and displays a notice to that effect, should be easy nuff, right sistpoty ? [20:31] I think that instead of "packaging" the word should be "maintain" or something instead [20:31] clearly the goal of a Jam is to find more MOTUs [20:31] imbrandon: -ENOPARSE... what should revu do? [20:31] sistpoty: I don't think it's related to that at all. Both are good, it's just that I (at least) would prefer bugfix as the default introduction. [20:32] jcastro: I'd much prefer a goal to find more Contributors, who may become MOTUs. [20:32] ah, good word. [20:32] sistpoty: check the time of the release ( maybe manualy set ) and display a notice about ..... i'll poke you after the meeting in #ubuntuwire [20:32] imbrandon: ok [20:32] persia: I don't think it's that simple. I think if this does result in actual work getting done, it's better for Ubuntu that it be fixing/upgrading than new packages. [20:33] So if we are going to support this initiative, I think it'd be good for it to focus on what we think most needs doing. [20:33] ScottK: I agree with jcastro that the focus is education & recruitment, rather than generating work done. [20:33] persia: EXACTLY [20:34] persia, ScottK: but we can agree that getting more contributors via loco teams is good? I think the tasks we support more or less for new contributors are a topic that not only affects loco teams, right? [20:34] I'd prefer bugfixing / upgrades, but I've seen a few people come from NEW who did good, so I won't shoot them. [20:34] sistpoty: Yes. [20:34] it doesn't say explicitly that jams are for new packages [20:35] [IDEA] jams are a means to get people involved for MOTU [20:35] IDEA received: jams are a means to get people involved for MOTU [20:35] sistpoty: I think that improving the MOTU/package ratio is good. It doesn't follow then that all ways of getting contributors are a positive. [20:35] ScottK: Sure, but that's rightly a separate topic/ [20:35] it seems people are equating "packaging" to mean new packages only, maintaince of packages falls under "packaging" and thus "packaging jams" [20:35] persia: I see it as core to how I feel about the idea. [20:36] imbrandon: Yes. It's entirely nomenclature. [20:36] yay \0/ [20:36] Well if you read the wiki about it, it's clearly orient towards new packages: https://wiki.ubuntu.com/MOTU/RunningPackagingJam [20:36] ok, how about generalizing the current topic then to new packages vs. bug fixing for motu-hopefuls (or any better fitted title)? [20:36] [LINK] https://wiki.ubuntu.com/MOTU/RunningPackagingJam [20:37] LINK received: https://wiki.ubuntu.com/MOTU/RunningPackagingJam [20:37] ScottK: sure, because thats what most new contributors are intrested in, but that dosent mean they will stay with that 100% forever etc, i started in the NEW queue :) [20:37] s/packagers/maintainers/, s/packaging/maintenance/ ? [20:37] persia: +1 [20:37] imbrandon: I did too, but that isn't the best way I think. [20:37] imbrandon: I disagree. Most people want to help, and don't have a lot of focus. [20:38] persia: Will you take an action to revise that wiki page then? [20:38] ScottK: we should still support all ways and not FORCE a contributor to do somehing they arent intrested in, thats why we have a low ratio now [20:38] ScottK: OK. [20:38] imbrandon: I totally agree with that. [20:38] imbrandon: Yes to not forcing, no to drawing conclusions therefrom [20:39] imbrandon: But I also think we should focus on people where we think we need them to work. (focus, not force). [20:39] ok, can we agree on updating the wiki? and any volunteers to get it right? [20:39] ScottK: too much focus seems like forceage lately IMHO [20:39] We already have more people plunking stuff onto REVU than MOTUs can handle. [20:39] * jonnymind is away: Sono occupato [20:39] * persia volunteers to just change language, but doesn't promise "right". [20:39] imbrandon: I agree and so a balance is needed. [20:39] persia: Sounds good. [20:40] [AGREED] persia to update the wiki about packaging jams [20:40] AGREED received: persia to update the wiki about packaging jams [20:40] [TOPIC] new packages vs. bugfixing as a means to get hopefuls involved [20:40] New Topic: new packages vs. bugfixing as a means to get hopefuls involved [20:41] I like both. I would like to deemphasize NEW packaging post DIF though. [20:41] We want people involved, but what we want to avoid is someone who is here to get $mypetpackage uploaded and vanishes. [20:41] ScottK: agreed [20:41] those are the ones you push to ppas. [20:42] or ignore. [20:42] getting a NEW package advocated take way more time that fixing a bug right ? [20:42] ScottK: I'm not sure about that: there's a few upstreams who want to do Ubuntu packaging, and I don't mind if they maintain their packages, and don't otherwise do much. [20:42] what I'd really like to see is some stats on how many packages that made it through revu are well-maintained and how many not [20:42] proppy: And it does. [20:42] ScottK: ignoring is bad, even in that sense [20:42] persia: I totally agree with that. [20:42] imbrandon: I'm thinking we have limited attention and can't properly attend to everyone, so we need to prioritize. [20:42] sistpoty: http://qa.ubuntuwire.com/uehs/ has a lot of your base data. About half are forgotten. [20:43] we need to go back to the first few cycles :-). pre REVU ;-) [20:43] Plus, even if we get a small fraction of "packaging jam target people" becoming MOTU short term, chances are they'll work on more MOTU-oriented thing in the future when they get more comfortable [20:43] jcastro: exactly, thats my point [20:43] "ok, you've done pet package, have you looked at doing a bite size bug?" etc. etc. [20:44] ScottK: I think we should actively process in REVU order. For most packages, it only takes 10-20 minutes to draft a basic review of why it isn't ready. I'd rather leave a comment & forget than ignore. [20:44] persia: where exactly? packages not in sync doesn't tell too much :/. packages w.o. watch file don't need to be orphaned. [20:44] Per maintainer lookups aren't exactly helpful in Ubuntu either. [20:44] jcastro: Good idea. Perhaps REVU uploaders should be encouraged to subscribe to the packages they upload in Malone. [20:44] from an early contributor POV, when you fix a bug you get the positive feedback sooner [20:45] [IDEA] subscribe REVU uploader to packages in malone [20:45] sistpoty: Look at packages w/o watchfile & the output of watchwiz for example. Further, between the three links is all the packages from REVU. [20:45] IDEA received: subscribe REVU uploader to packages in malone [20:45] What would be the purpose of this? [20:45] +1, this should be being done now anyhow as best practice [20:46] I disagree. [20:46] ScottK: make the people that rovide $package get bugmail [20:46] Ah. I see. I misunderstood [20:46] ScottK: If someone packages & uploads, encouraging them to watch bugs in that package may encourage greater involvement. Not mandatory, just encouraged. [20:46] * ScottK was thinking you were referring to the needs-packaging bug. [20:46] No. No point really. [20:46] persia: Yes, that's good. I just misundersood. [20:47] The problem is that there's nothing to subscribe to until after the upload. [20:47] So you have to ask them to do it after. [20:47] yep, maybe suscribe the dependencies :) [20:47] ScottK: there is nothing to apply a bug to before upload either :-) [20:47] ScottK: sure, you shouldent just $upload and forget about someone :) [20:47] proppy: Less likely. Not everyone can debug e.g. glibc [20:47] so that shouldent be an issue [20:47] OK. Good enough. [20:48] persia: nor python [20:48] proppy: exactly [20:48] Getting a bug point of contact (even if they can only triage) is a very good thing. [20:48] * persia hopes for the next topic, in anticipation of going back to sleep [20:49] I'm done. Anyone else have a topic? [20:49] ok, anyone disagrees with persia? [20:49] I think we have an agree here somewhere? :-) [20:49] hehe [20:49] any other business? [20:49] as long as its best practice and not manditiory :) [20:49] imbrandon: No enforement mechanism, so no point in calling it "mandatory". [20:50] 3... [20:50] 2... [20:50] 1... [20:50] what do you think about MOTU helpfull revu others MOTU packages [20:50] ? [20:50] (sorry) [20:50] [TOPIC] having motu hopefuls review other MOTU packages [20:50] proppy: As lolng as you make it clear you're not a MOTU, I think it's great. [20:50] New Topic: having motu hopefuls review other MOTU packages [20:50] we have a bad habbit about making things "required" though before they are put into use for a while, unlike debian policys where they are used for a long time before they are policy [20:50] proppy: It's good. It's encouraged, and no they can't have access to REVU to do it yet. [20:50] and MOTU reviewing you'r review [20:51] persia: they can, but only on a individual basis [20:51] proppy: If you do the review interactively on #ubuntu-motu then that happens automatically. [20:51] imbrandon: agreed. [20:51] sistpoty: Yes, but we can't distinguish Contributor comments from MOTU comments for sort order, so it breaks the MOTU review of Contributor comments part of the goal. [20:52] sistpoty: That needs to be treated as a special case and not as a general capability right now. [20:52] proppy: If you're worried about flooding the channel, use a pastebin to write the review, and post the link to #ubuntu-motu [20:52] persia: right. but I guess someone who does a good job for some time should get review rights... [20:52] persia: ok [20:52] ScottK: exactly, that's what I wanted to write [20:52] it was just a suggestion [20:52] sistpoty: shouldn't that person be a MOTU as well then? [20:52] I like this proposal. A non-MOTU can provide useful feedbacks, reviewer will choose to follow these advices or not. [20:52] proppy: It's a good one. [20:52] sistpoty: I disagree. If someone is doing an excellent job of reviewing, they should be prodded to apply for MOTU. [20:52] maybe a threaded forum is more approriate for that than revfu [20:53] persia: Think of it as a final exam. [20:53] Nafallo, persia: sure, but there are always delays, and I recall having someone grant review rights as a task of the application *g* [20:53] ScottK: For some special cases, maybe. [20:54] I guess we all can agree that the real bug is in revu, which should get fixed, right?= [20:54] And since we haven't mechanized a way to distinguish MOTU/non-MOTU comments, then a special case is all it can ever be until someone codes the changes in REVU. [20:54] sistpoty: That might happen, but it's part of the application process, not a general case: Contributors should first prove their reviewing skills in #ubuntu-motu [20:55] persia: I guess we agree there :) [20:55] what about posting review in a mailing list then ? [20:55] proppy: that mailing list exists already: motureviewers@tauware.de ;) [20:56] then distingish between motu and non motu is just a matter of identify ? [20:56] proppy: Be warned that not every uploader reads that list (nor every reviewer) [20:56] like an @ubuntu.com email ? [20:56] motu-reviewers even [20:56] proppy: The trick is the data base schem needs changing. [20:56] proppy: Essentially. It's not email, it's membership in ~ubuntu-dev [20:57] proppy: Not all MOTUs use their ubuntu.com address. [20:57] ScottK: we could abuse the current scheme a little bit... I guess there's some space left which would require only minimal changes (but those with care *g*) [20:57] @ubuntu.com is for members, not developers. [20:57] ScottK: you mean not at all ? [20:57] ScottK: or not for reviewing business ? [20:58] sistpoty: Excellent. [20:58] proppy: I meant not at all. [20:58] ScottK: ok ne [20:58] * ScottK for example. [20:58] * persia proposes the drafting of a spec for how non-MOTUs would comment, for general review [20:58] [IDEA] fix revu to allow non-motu contributors [20:58] IDEA received: fix revu to allow non-motu contributors [20:58] persia: that would be excellent, would you take care for this? [20:58] thanks for feedbacks [20:59] sistpoty: I don't understand the problem well enough: I was happy using pastebin as a Contributor. [20:59] proppy: Would you be up for drafting a spec for how Contributors would add REVU comments? [20:59] proppy: How about you make a first draft? [20:59] persia: np [20:59] pastebin requires IRC :( [20:59] proppy: Thanks. [20:59] persia: the difference betweend pastbin and revu [20:59] persia: it would be in place reviews... debian-mentors acts quite like this [20:59] imbrandon: I don't consider that a downside. [20:59] persia: is that pastebin is live [21:00] persia: REVU is asynchronous [21:00] proppy: It alse needs to talk about how it gets decided who can review. [21:00] (the mailing list, not the webpage= [21:00] persia: i do, i know many contributors i have worked with will NOT cone to IRC [21:00] come* [21:00] proppy: True. I'll probably have more useful input when more awake :) [21:00] hehe [21:00] should I use the spec template ? [21:01] plus irc limits you to those that are in your timezone [21:01] or sleep/schedule [21:01] imbrandon: Sleep is for the weak. [21:01] hehe [21:01] proppy: That would be best. [21:01] proppy: I guess just informative text is nice.. of course you can do an "official spec" if you want ;) [21:01] persia: url ? [21:01] persia: I mean of the wanted spec [21:02] persia: not the template [21:02] ok i got to run, i trust someone will post the minutes to the ML ? [21:02] imbrandon: sure, I'll do [21:02] Maybe sistpoty would volunteer to mentor proppy on spec writing.... [21:02] killer, thanks [21:02] * persia suggests https://wiki.ubuntu.com/Spec/ContributorREVU but thinks someone else might have a better suggestion. [21:02] https://wiki.ubuntu.com/MOTU/NonMOTUReviewProcess ? [21:02] ScottK: /me needs the spare time for rewriting revu :P [21:03] sistpoty: You don7t get to rewrite until there's a spec, no? ;) [21:03] I suck when it comes to choosing CamelCasedNames [21:03] sistpoty, is source code available somewhere? [21:03] sistpoty: i just started proding the codebase too and did you see the staging site yet ? [21:03] DktrKranz: In the LP project [21:03] ah, I'll have a look, then [21:03] [LINK] https://wiki.ubuntu.com/Spec/ContributorREVU [21:03] LINK received: https://wiki.ubuntu.com/Spec/ContributorREVU [21:04] DktrKranz: sure, https://code.launchpad.net/~revu-hackers/revu/trunk [21:05] imbrandon: no, not yet [21:05] ok, shall we move on? [21:05] * persia seconds [21:05] sistpoty: if that means a countdown ;-) [21:05] 3 [21:05] 2 [21:05] 1 [21:05] any other business? [21:06] Next meeting? [21:06] * persia proposes 12:00 UTC 21st December 2007 [21:06] [TOPIC] next meeting [21:06] New Topic: next meeting [21:06] Sounds good to me [21:06] * persia proposes 12:00 UTC 21st December 2007 [21:06] (for MootBot) [21:06] I'm on a flight :-) [21:06] [IDEA] persia 12:00 UTC 21st December 2007 [21:06] IDEA received: persia 12:00 UTC 21st December 2007 [21:06] persia: I doubt we'll get much that close to Christmas [21:06] How about 12/14 and then we skip a week? [21:06] ScottK: True, but the week after is even worse :( [21:07] friday meetings is the rule? ;-) [21:07] * persia doubts much of an agenda pre-12/14 (and couldn't make it anyway) [21:07] Nafallo: Not the rule, but the practice. [21:08] persia: Even without an advance agenda, meetings are good. [21:08] I think today is an excellent example of that. [21:08] 4th then? :-) [21:08] official christmas break is "only" at 12/27 (https://wiki.ubuntu.com/HardyReleaseSchedule), so I'd favor 12/12 [21:08] 12/21 even [21:09] oh [21:09] it's m/dd [21:09] mm even [21:10] so? [21:10] * DktrKranz likes 12/21 [21:10] Whatever. [21:10] we got 14th, 21st and 4th proposed :-P [21:10] let's vote... didn't have the chance to do a MootBot vote yet *g* [21:10] [vote] meeting on 14 [21:10] Please vote on: meeting on 14. [21:10] Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0 to MootBot [21:10] E.g. /msg MootBot +1 #ubuntu-meeting [21:11] +0 [21:11] Abstention received from sistpoty. 0 for, 0 against. 1 have abstained. Count is now 0 [21:11] -1 [21:11] -1 received from persia. 0 for, 1 against. 1 have abstained. Count is now -1 [21:11] -1 [21:11] -1 received from DktrKranz. 0 for, 2 against. 1 have abstained. Count is now -2 [21:11] -1 [21:11] -1 received from Nafallo. 0 for, 3 against. 1 have abstained. Count is now -3 [21:11] -1 [21:11] -1 [21:11] -1 received from geser. 0 for, 4 against. 1 have abstained. Count is now -4 [21:11] -1 received from imbrandon. 0 for, 5 against. 1 have abstained. Count is now -5 [21:11] [endvote] [21:11] Final result is 0 for, 5 against. 1 abstained. Total: -5 [21:11] [vote] meeting on 21 [21:11] Please vote on: meeting on 21. [21:11] Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0 to MootBot [21:11] E.g. /msg MootBot +1 #ubuntu-meeting [21:11] +0 [21:11] Abstention received from imbrandon. 0 for, 0 against. 1 have abstained. Count is now 0 [21:11] -1 [21:11] -1 received from Nafallo. 0 for, 1 against. 1 have abstained. Count is now -1 [21:11] +1 [21:11] +1 received from DktrKranz. 1 for, 1 against. 1 have abstained. Count is now 0 [21:12] +1 [21:12] +1 received from sistpoty. 2 for, 1 against. 1 have abstained. Count is now 1 [21:12] +1 [21:12] +1 received from geser. 3 for, 1 against. 1 have abstained. Count is now 2 [21:12] +1 [21:12] +1 received from persia. 4 for, 1 against. 1 have abstained. Count is now 3 [21:12] [endvote] [21:12] Final result is 4 for, 1 against. 1 abstained. Total: 3 [21:12] [vote] meeting on 4th [21:12] Please vote on: meeting on 4th. [21:12] Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0 to MootBot [21:12] E.g. /msg MootBot +1 #ubuntu-meeting [21:12] 0 [21:12] +0 [21:12] +1 [21:12] -1 [21:12] Abstention received from DktrKranz. 0 for, 0 against. 1 have abstained. Count is now 0 [21:12] +1 received from Nafallo. 1 for, 0 against. 1 have abstained. Count is now 1 [21:12] -1 received from sistpoty. 1 for, 1 against. 1 have abstained. Count is now 0 [21:12] +1 [21:13] +1 received from imbrandon. 2 for, 1 against. 1 have abstained. Count is now 1 [21:13] +0 [21:13] Abstention received from persia. 2 for, 1 against. 2 have abstained. Count is now 1 [21:13] +1 [21:13] +1 received from ScottK. 3 for, 1 against. 2 have abstained. Count is now 2 [21:13] +0 [21:13] Abstention received from geser. 3 for, 1 against. 3 have abstained. Count is now 2 [21:13] [endvote] [21:13]