[10:51] <dholbach> ?
[10:52] <jsgotangco> :)
[10:52] <dholbach> sorry
[10:53] <jsgotangco> ah
[03:19] <juliux> @schedule berlin
[03:19] <Ubugtu> Schedule for Europe/Berlin: 15 Dec 21:00: MOTU | 19 Dec 21:00: Technical Board | 20 Dec 21:00: Edubuntu | 21 Dec 22:00: Ubuntu Development Team | 27 Dec 13:00: Edubuntu | 28 Dec 09:00: Ubuntu Development Team
[03:21] <Maikel> @schedule amsterdam
[03:21] <Ubugtu> Schedule for Europe/Amsterdam: 15 Dec 21:00: MOTU | 19 Dec 21:00: Technical Board | 20 Dec 21:00: Edubuntu | 21 Dec 22:00: Ubuntu Development Team | 27 Dec 13:00: Edubuntu | 28 Dec 09:00: Ubuntu Development Team
[04:41] <Reichstag> http://www.priceslashsoftware.com - These programs (e.g. Adobe Acrobat) may be downloaded after paying. So are these programs legal after payment?
[04:54] <Toadstool> @schedule los_angeles
[04:54] <Ubugtu> Schedule for America/Los_Angeles: 15 Dec 12:00: MOTU | 19 Dec 12:00: Technical Board | 20 Dec 12:00: Edubuntu | 21 Dec 13:00: Ubuntu Development Team | 27 Dec 04:00: Edubuntu | 28 Dec 00:00: Ubuntu Development Team
[04:58] <nixternal> los_angeles + 2 = chicago
[04:59] <Toadstool> :)
[06:04] <amendt> What is more costly? 1. Hosting the software and all the security fixes or 2. Programing better code (assuming normal hourly wages)  backdrop Microsoft ignores fixing its Word wordprocesor is that because no programer knows how to fix it or is too costly to upload all the fixes?
[08:03] <mruiz> hello mvo
[08:23] <mruiz> ping nixternal
[08:27] <nixternal> pong mruiz
[08:59] <nixternal> hola
[08:59] <dholbach> Hello everybody
[09:00] <ajmitch> daniel!
[09:00] <Toadstool> heya!
[09:00] <bddebian> Heya gents
[09:00] <dholbach> Let's get started
[09:01] <sistpoty> hi folks
[09:01] <dholbach> It's nice to have a MOTU meeting again and we even have an agenda!
[09:01] <dholbach> https://wiki.ubuntu.com/MOTU/Meetings
[09:01] <ajmitch> thanks to sistpoty for getting this organised
[09:01] <dholbach> sistpoty and other put "Set agenda for MOTU Council" on the agenda... so why not start with that? :)
[09:01] <mruiz> hello everybody
[09:01] <sistpoty> sounds sane
[09:02] <sistpoty> dholbach: will you give us a short introduction to the planned motu council and the status?
[09:02] <dholbach> Alrighty... I hope everybody had a look at https://wiki.ubuntu.com/MotuProcessesSpec already
[09:02] <ajmitch> aka council grayskull :)
[09:02] <dholbach> it's a spec that was written during UDS and we had quite some MOTU participation on it
[09:03] <dholbach> two things came together in that time: first: we wanted to speed up and improve some of processes
[09:03] <dholbach> second: the TB and CC wanted to delegate their power to approve ubuntu-dev members to another council
[09:04] <dholbach> the spec is approved by the TB already and the next TB meeting will get the Council started
[09:04] <dholbach> the council will consist of five people who will do the following jobs:
[09:05] <dholbach>  * approve new MOTUs (this is a good thing since we know the people best and will have more time during our meetings), however the TB will have the final word (this will be done via email)
[09:05] <zul>  /win 10
[09:05] <dholbach>  * organize MOTU processes
[09:05] <dholbach>  * run regular meetings
[09:05] <dholbach>  * deal with problems that might come up
[09:05] <dholbach> are there any questions up until now?
[09:06] <crimsun_> (all clear here.)
[09:06] <zul> nope
[09:06] <dholbach> Ok cool.
[09:06] <mruiz> no questions
[09:06] <dholbach> Are there any other tasks that you can think of, the MOTU Council should take over?
[09:07] <ajmitch> (given that it'll be 5 busy people anyway)
[09:07] <ajmitch> loading the council members with too many tasks may doom it to failure
[09:07] <dholbach> I want to clarify the point 'organize MOTU processes' a bit. This of course does not mean that the Council will just decide. We will try to get a consensus wherever we can.
[09:08] <dholbach> The Council will have to organize all the related Council processes very clearly, to avoid what ajmitch just said.
[09:08] <mruiz> what's about design a roadmap to help people to join MOTU team?
[09:08] <zul> whats the term of the council?
[09:08] <dholbach> The Council will want to keep the work load small
[09:08] <crimsun_> zul: I was just going to ask that. :)
[09:09] <minghua> does the council need to delegate some of the tasks?
[09:09] <crimsun_> I propose that the term corresponds in length with the SRU team's.
[09:09] <minghua> because I see a lot of stuff to do in the spec
[09:09] <dholbach> zul: i'll add that to the spec, I suggest one year, but it's not in the spec - that's something the TB should be able to clarify.
[09:09] <dholbach> crimsun_: half a year?
[09:09] <ajmitch> minghua: delegation will be done, certainly
[09:09] <ajmitch> motus aren't going to get off lightly :)
[09:09] <crimsun_> dholbach: yes
[09:09] <bddebian> darn
[09:10] <dholbach> crimsun_: my concern is that setting up a new council might take a while
[09:10] <dholbach> crimsun_: but I'll leave that up for discussion for the TB meeting
[09:10] <ajmitch> especially as it requires approval by TB
[09:11] <dholbach> added that to the spec
[09:11] <crimsun_> dholbach: true. We could stagger the selections, then, to occur say one month in advance of the new Council's start.
[09:11] <sistpoty> dholbach: how long do you estimate that it takes until the new council is in place?
[09:11] <dholbach> Are there any questions about the new MOTU approval process?
[09:11] <dholbach> crimsun_: if you want to add that to the spec document, that's cool with me.
[09:11] <crimsun_> dholbach: ok, queued.
[09:11] <dholbach> sistpoty: I have Mark's word on "next TB meeting (unless there are objections)"
[09:12] <dholbach> sistpoty: from what I've heard they're very happy to delegate the task, so I imagine it won't take long
[09:12] <dholbach> sistpoty informed me there was a discussion around having an Interim Council
[09:13] <dholbach> I'd prefer to not have to do this. I know that we're all keen to see the Council in place, but I'm not convinced that it would be worth the effort to create one
[09:13] <sistpoty> dholbach: are the members elected/chosen (on what base)/determined by random() *g*?
[09:13] <ajmitch> when is next TB meeting? january?
[09:13] <dholbach> I additionally don't see where we are blocked at the moment without such a Council (until the TB meeting).
[09:13] <dholbach> ajmitch: I suppose so
[09:14] <ajmitch> hey siretart
[09:14] <dholbach> sistpoty: I talked to a couple of people and asked them if they could imagine being on that Council - in the end only the TB and CC will decide
[09:14] <dholbach> and we'll see the decision coming on soon
[09:14] <dholbach> Are there any questions about the new MOTU approval process?
[09:15] <sistpoty> dholbach: so you make a suggestion to the tb, and they will decide?
[09:15] <siretart> I remeber that there was some discussion about not approving new ubuntu-dev members, because there will be a motu concil in place soon
[09:15] <dholbach> siretart: it would require us to vote and set it up and I'm really not sure what value it'd have for the 2-3 weeks - especially given the fact that we didn't have a council for 2 years
[09:16] <sistpoty> well, we could vote right now, couldn't we?
[09:16] <sistpoty> (just as a side remark)
[09:16] <siretart> dholbach: ah, so we want to have a lp vote for, lets say 2 weeks?
[09:16] <dholbach> And overruling people who are not here?
[09:16] <dholbach> and then have a new council 2 weeks later?
[09:16] <dholbach> Which decisions do you think will have to be made during that time?
[09:17] <siretart> new developers?
[09:17] <dholbach> sistpoty: I passed on the information I have about people who could imagine to be on the Council - the TB and CC have a good overview over our ubuntu-dev and ubuntu-core-dev members themselves and they will do the decision
[09:17] <sistpoty> siretart: no, new developers would still mean tb
[09:17] <dholbach> exactly
[09:17] <siretart> I'm not sure if the TB is too happy with this
[09:17] <dholbach> the council didn't get the powers delegated yet, so it cannot do that decision
[09:17] <sistpoty> dholbach: so, there is never gonna be a vote anyways?
[09:18] <dholbach> as far as I know, no
[09:18] <sistpoty> ah, k
[09:18] <crimsun_> I agree with Daniel on this one; it's the holidays, so most people are unlikely to devote much time. We'll have some people ("regulars"?) around to address new people interested in helping/starting out. It wouldn't be any different to simply wait for TB's approval next month.
[09:18] <dholbach> Thanks Daniel.
[09:18] <crimsun_> Imo we've already cleared the qualified MOTU candidates as of last TB.
[09:19] <bddebian> hmm
[09:19] <dholbach> What can really help is: as soon as questions or problems creep up: add them to a wiki page, so this can be discussed in the first council meeting.
[09:19] <dholbach> the more detailed the information, the better
[09:19] <ajmitch> the most pressing need that the council will fill, is something that any of us can do - directing new people where to go, giving people an idea of what to do
[09:19] <sistpoty> given the fact, that tb meeting is RSN, and there won't be any more delays (like voting or s.th. *g*), I'm all for not setting up s.th. else in the meantime
[09:20] <crimsun_> agreed.
[09:20] <siretart> k
[09:20] <dholbach> Alright... do you see anything else that belongs to "agenda for MOTU Council"?
[09:21] <giskard> hi *
[09:21] <dholbach> hello Riccardo
[09:21] <sistpoty> dholbach: nope, from my side
[09:21] <siretart> dholbach: just a sek. how will the council actually be appointed?
[09:21] <imbrandon> re
[09:21] <imbrandon> sorry i'm late
[09:21] <dholbach> Ok, if anything creeps up, either add it to the comments section of the MotuProcessesSpec page or we create a new page for the CouncilAgenda
[09:22] <ajmitch> siretart: names being submitted by dholbach to the TB
[09:22] <giskard> sorry if i'm late :(
[09:22] <siretart> I read by vote, but I miss the details (or if this is out of scope of this meeting, let's move it to -motu)
[09:22] <dholbach> ajmitch: no
[09:22] <giskard> hi Daniel.
[09:22] <dholbach> ajmitch: that's not true
[09:22] <dholbach> the TB and CC will decide
[09:22] <dholbach> I was merely asked to ask a few people I could think of, if they could imagine being on the Council
[09:22] <ajmitch> and I thought they were deciding from a shortlist you gave them?
[09:22] <ajmitch> ok..
[09:22] <dholbach> they have a good overview of their own
[09:23] <dholbach> I want to avoid the impression that I choose people who are on the council
[09:23] <sistpoty> hm... so it will take at least a TB + CC meeting?
[09:23] <dholbach> I don't have the power to do that.
[09:23] <imbrandon> i thought the TB was only ACK'ing what we decided? thats what we said at UDS
[09:23] <minghua> so it's purely decided by CC+TB?
[09:24] <dholbach> imbrandon: that has already happened, it's just the appointment of the council members, we're talking about at the moment
[09:24] <dholbach> minghua: yes
[09:24] <siretart> dholbach: the confusion is not that we do (not) want to decide or not who get's in the council. the way it is constituted seems to be quite unclear
[09:24] <imbrandon> dholbach: ahh then who is the TB acking ?
[09:24] <cjwatson> just the TB, AFAIK
[09:24] <dholbach> cjwatson: Ok, sorry. Thanks for the clarification.
[09:24] <cjwatson> as far as I know, the MOTU Council is a straight delegation from the TB
[09:25] <minghua> so how is the second term of the council formed?  appointed by CC+TB again?
[09:25] <cjwatson> that I'm not sure about, and will wander off again ...
[09:25] <dholbach> imbrandon: the TB will ACK new members of ubuntu-dev, after the MOTU council came to a conclusion abou them.
[09:25] <cjwatson> I think you should propose something to the TB :-)
[09:25] <imbrandon> right i mean the members that will make the council
[09:25] <imbrandon> dholbach: ^
[09:25] <dholbach> minghua: I suppose so - that has not been clarified yet - I'll add it to the spec
[09:26] <dholbach> imbrandon: the MC will be formed and appointed by the TB
[09:26] <imbrandon> dholbach: in UDS we said that you will choose a council to be approved by the TB , afaik
[09:26] <imbrandon> if thats changed
[09:26] <imbrandon> thats whats unclear to me
[09:26] <siretart> dholbach: is it just me or does the fact that the TB has to ACK an applicant as well makes the process more complicated than it currently is?
[09:26] <dholbach> no, I don't have the power to do that
[09:27] <dholbach> siretart: no, it will be a simple thing, done by email
[09:27] <dholbach> I don't think it will take long
[09:27] <dholbach> it will be more of a formal thing
[09:27] <siretart> dholbach: aha? so there will be a tb discuss mailing list? or will the discussion be in private?
[09:28] <dholbach> there's a technical-board mailing list already
[09:28] <imbrandon> so the TB is just going to pick random MOTU's or is someone nomniating them ?
[09:28] <imbrandon> ( for the council )
[09:28] <siretart> dholbach: it is? I fail to spot it on https://lists.ubuntu.com/mailman/listinfo/
[09:28] <dholbach> siretart: it's private
[09:29] <dholbach> imbrandon: I was asked to ask a few people if they could imagine being on the council, I passed on that information, but they make up their own minds, they know all the people in ubuntu-dev well enough
[09:29] <imbrandon> ahh ok
[09:29] <dholbach> I doubt they'll choose "random"ly
[09:29] <siretart> mh. I'd really appreciated that the discussion of new members was public
[09:29] <bddebian> Why not, wouldn't that be more fun? :-)
[09:29] <siretart> s/I'd/I have/
[09:30] <sistpoty> did my bribery get through to tb? *g*
[09:30] <dholbach> siretart: it will be a formal quick thing - we can talk about that still
[09:30] <imbrandon> siretart: it is public afaik the TB is deligating that to the MOTU council, the only thing will be that TB physicly puts them into the LOP team
[09:30] <siretart> dholbach: but you see that we loose transparency?
[09:30] <imbrandon> s/LOP/LP
[09:30] <siretart> imbrandon: not from what I get from this discussion.
[09:31] <cjwatson> the TB meeting appointing the MOTU council will be public, though
[09:31] <siretart> imbrandon: to me, it seems that the motu council doesn't decide, but only make suggestions to the tb. the actual approval seems to be to be done in private by the TB
[09:31] <imbrandon> wrong
[09:31] <dholbach> siretart: It will be part of the MC reporting to the TB. They have Launchpad powers to add people to ubuntu-dev.
[09:31] <cjwatson> no, it's done in public by the TB
[09:31] <cjwatson> siretart: hang on, you mean the approval of new members, or the approval of the MOTU council?
[09:31] <dholbach> siretart: there's no further evaluation and secret discussion
[09:32] <siretart> cjwatson: I'm talking about approval of new members of the ubuntu-dev group
[09:32] <cjwatson> siretart: then what dholbach said matches my understanding too. The MOTU council is just teleoperating the TB, basically ...
[09:32] <sistpoty> well, if the MC will make suggestion, they'll certainly get to know the facts. MC could add the transparancy layer than again
[09:32] <sistpoty> (or should=
[09:32] <imbrandon> siretart: past when the MOTU Council approves a new ubuntu-dev the TB will only put them in LP, they dont "approve" them any further
[09:33] <siretart> imbrandon: aah, so that part gets done in private, right?
[09:33] <imbrandon> right
[09:33] <dholbach> the MC will report publically to the TB, the TB will do the Launchpad change
[09:33] <cjwatson> insofar as there's anything to be public ...
[09:33] <cjwatson> it's an https connection to launchpad.net; I guess that's private ;-)
[09:33] <giskard> imbrandon, why MC cannot do this, in fact TB is deligating them to do some of theyr work?
[09:33] <imbrandon> dholbach: exactly, we are asll on the same page now, we were all just saying it diffrently
[09:33] <siretart> I'd suggest to make this very very clear. for outsiders, it may look like that the decision who gets developers is done by canonical, which *could* have a hidden agenda for (not) approving members
[09:34] <dholbach> siretart: TB != Canonical
[09:34] <cjwatson> the TB has non-Canonical members, in fact
[09:34] <imbrandon> where does canonical come into play?
[09:34] <siretart> I don't want that this impression gets a rumor
[09:34] <dholbach> Ok... any other questions or things we should clarify?
[09:34] <cjwatson> (well, member)
[09:34] <giskard> only mjg59 .
[09:34] <crimsun_> siretart: we'll make that clear as part of the secretarial process in MOTU on the wiki.
[09:34] <giskard> afaik.
[09:34] <siretart> dholbach: for outsiders, it doesn't matter. I know many many many debian developers, who don't get the difference
[09:34] <cjwatson> giskard: yes
[09:34] <siretart> dholbach: thats why I suggest to make this fact very very clear
[09:34] <dholbach> siretart: Right, we will make the process VERY clear.
[09:35] <dholbach> Agreed, let's move on.
[09:35] <siretart> it is already confusing now!
[09:35] <siretart> k
[09:35] <sistpoty> dholbach +1
[09:35] <sistpoty> btw.: is anybody doing the minutes actually?
[09:35] <dholbach> Any other questions or suggestions about the duties of a MC member?
[09:35] <imbrandon> one last question about the MC? when is the TB going to form the MC?
[09:35] <ajmitch> sistpoty: are you volunteering, or do you want me to?
[09:35] <dholbach> imbrandon: next TB meeting
[09:36] <imbrandon> dholbach: okies
[09:36] <sistpoty> ajmitch: would be very cool, if you could do it
[09:36] <crimsun_> I believe those four points that Daniel stated are significant (enough) in scope. :)
[09:36] <dholbach> Alright: next point: Review processes (REVU, bzr, SRU, merges, etc.) (sistpoty)
[09:37] <sistpoty> hm... well, with what to start?
[09:37] <sistpoty> I guess I'll go through it in order
[09:37] <dholbach> Ok
[09:37] <sistpoty> I'd first like to talk about revu and your idea about bzr to do reviews
[09:37] <imbrandon> brb
[09:38] <sistpoty> well, I've already written some stuff about this on the ml, so I'll try a short summary
[09:38] <dholbach> I hope everybody read https://wiki.ubuntu.com/CodeReviewSLA or the mail I sent to ubuntu-motu@ a while ago
[09:38] <sistpoty> revu's throughput is suboptimal *cough*
[09:38] <sistpoty> dholbach came up with the codeReviewSLA spec
[09:38] <bddebian> You think? :-)
[09:39] <sistpoty> bddebian: yay, you cleaned up much, I know :)
[09:39] <dholbach> Yes, what I tried to achieve was: people helping each other before things get reviewed and lets us go through n+1 iterations
[09:39] <dholbach> my personal experiences with using bzr for packaging in a team were great
[09:39] <siretart> the jumping point is that it is unclear how we get more reviewers with having the packages in bzr on launchpad?
[09:39] <sistpoty> which in principle is a good idea
[09:39] <dholbach> giskard can probably acknowledge
[09:39] <sistpoty> exactly siretart
[09:40] <dholbach> the idea doesn't buy us reviewers
[09:40] <dholbach> it's just that people can check their team mates packaging and do changes on the fly
[09:40] <sistpoty> and imo using only the bzr-thingy to review stuff makes the job much harder than it's now
[09:40] <dholbach> you check it out, do changes, commit it
[09:40] <nixternal> nice
[09:40] <sistpoty> imo, we should have a clear separation of the two involved processes:
[09:41] <siretart> which is cool, but a different issue to 'reviewing' packages
[09:41] <dholbach> sistpoty: I agree that there are unresolved issues, but we're good at solving problems, I'm sure that if we hack up revu-tool or revu-check it will do bits of the job for us
[09:41] <sistpoty> 1) preparing a package (this includes collaboration)
[09:41] <sistpoty> 2) the final review of the package
[09:41] <sistpoty> for 1) bzr and the spec is very well fit
[09:41] <minghua> and there is still a learning curve (steep or not) to consider, I suppose
[09:42] <sistpoty> for 2) we'll be much better of with revu imo
[09:42] <dholbach> minghua: we have to have good documentation - I had artists working with bzr and doing a really good job at it in no time
[09:42] <dholbach> sistpoty: why?
[09:42] <giskard> sistpoty, no, ihmo bzr will help us a lot! as seb128 pointed in  codeReviewSLA we need to have a bzr-buildpackage that works out of the box. It will be more easy for use if we have  only to type a "bzr branch $something" and "bzr-buildpackage"
[09:43] <crimsun_> Honestly, I don't think 2) has anything to do with whether we use REVU or LP's bzr.
[09:43] <ajmitch> one problem is that we often use REVU as a teaching tool, where we wait for the people submitting packages to make fixes we suggest
[09:43] <siretart> giskard: there is a bzr plugin for building packages. I tried it on my laptop yesterday, it seems to be quite nice
[09:43] <sistpoty> dholbach: how could I say with bzr "this version is good" or "you have that and that error in there"
[09:43] <giskard> and yes, as dholbach said, maintain packages in bzr is great, we did it for telepathy and galago.
[09:44] <dholbach> sistpoty: you can use the bzr branch whiteboard and/or changes with a good commit entry to do that
[09:44] <sistpoty> dholbach: if I'd commit changes, it would be a mix up of 1) and 2) again
[09:44] <dholbach> siretart: that's cool - it'd be nice if you coud explain that in a blog post or on ubuntu-motu@ or something
[09:44] <siretart> I think dholbach's point is, that we shouldn't focus on telling hopefuls what is wrong in their packages, but rather fixing them, right?
[09:44] <minghua> dholbach: the problem is, all reviewers need to learn these if they are not already using bzr
[09:44] <ajmitch> siretart: it depends if we want to spend more time fixing than teaching
[09:45] <dholbach> siretart: I'm not going to fix package for all MOTU hopefuls, I said that it's an option and I think it's a good one
[09:45] <siretart> dholbach: I'm planning to try it out with a repackaged xine. will blog about that. not all dependencies are in feisty (yet)
[09:45] <seb128> bzr is easy to use, not an huge learning curve
[09:45] <minghua> and I don't know if any hopeful will be intimidated by bzr
[09:45] <dholbach> I think we should really try it and fix problems along the way
[09:45] <siretart> dholbach: still, the abilities of launchpad to comment on particular revisions of a bzr branch are poor
[09:45] <crimsun_> minghua: there's olive, too.
[09:45] <dholbach> I know there are issues, but I'm sure we'll tackle them
[09:45] <bddebian> LaserJock!
[09:46] <dholbach> siretart: the commit log helps with that
[09:46] <LaserJock> yeah, yeah, got stuck in a meeting
[09:46] <seb128> random comment from main uploader, I don't use REVU because I never bothered to register so I would find bzr on launchpad easier and would probably review some package on it
[09:46] <dholbach> siretart: it preserves history
[09:46] <sistpoty> hm... I wouldn't personally like to run in s.th. that's producing more work for the reviewers. these are our real bottleneck!
[09:46] <dholbach> seb128: more desktop crack! :-)
[09:46] <seb128> :)
[09:46] <siretart> dholbach: and how do you actually comment? using the whiteboard isn't that satisfying to me :(
[09:46] <dholbach> sistpoty: I agree, we have to bear that in mind
[09:46] <ajmitch> LaserJock: don't worry, we're still slogging through the agenda :)
[09:47] <dholbach> siretart: that's why I suggested the bzr commit log
[09:47] <ajmitch> dholbach: that requires having changes to commit
[09:47] <LaserJock> can we create a comment page that links to the bzr LP?
[09:47] <dholbach> ajmitch:   --unchanged           commit even if nothing has changed
[09:47] <siretart> ajmitch: if you fix the issues pointed in place, you have something to commit
[09:47] <seb128> if you need something for the lp guys just speak to them with some rational
[09:47] <ajmitch> dholbach: scary
[09:47] <dholbach> LaserJock: what do you mean?
[09:48] <seb128> dholbach: like a wiki page probable
[09:48] <crimsun_> Could we see gobby fitting into this?
[09:48] <seb128> probably
[09:48] <LaserJock> like have a page on tiber that get's updates
[09:48] <sistpoty> seb128: personalpackagearchive?
[09:48] <dholbach> seb128: for the issues we identify?
[09:48] <giskard> dholbach, i guess send the commit messages to a web-page. something like send them via mail.
[09:48] <siretart> dholbach: interesting idea
[09:48] <dholbach> LaserJock: updates of changed branches?
[09:48] <seb128> dholbach: for any comment if the lp witheboard is not enough
[09:48] <dholbach> seb128: right
[09:48] <LaserJock> commenting
[09:48] <dholbach> I filed a couple of bugs on launchpad-bazaar which are added to the spec
[09:48] <seb128> I think that the whiteboard is enough though
[09:49] <seb128> note things to fix
[09:49] <dholbach> we need proper email reporting, no doubt about that
[09:49] <LaserJock> I just don't see how a bzr repo of the debian/ is going to give us enough info
[09:49] <seb128> delete them when fixed
[09:49] <dholbach> LaserJock: we still need to discuss how we're going to solve the tarball / upstream source issue
[09:49] <dholbach> but please let's not do that here
[09:49] <dholbach> I'm sure we come up with something creative
[09:49] <seb128> (put the source package on launchpad)
[09:50] <dholbach> yeah, something like that
[09:50] <giskard> why?
[09:50] <seb128> because it's easier
[09:50] <seb128> until you get a working bzr-buildpackage
[09:50] <giskard> ah ok
[09:50] <siretart> dholbach: how about introducing a new X- field in debian/control pointing to the source tarball?
[09:50] <dholbach> siretart: fine with me
[09:50] <crimsun_> ok, let's summarise: We're migrating from REVU to LP's bzr for packaging, and we'll use LP's whiteboard for commenting.
[09:50] <dholbach> revu-tools <LP branch>        could then build the package and run lintian on it
[09:51] <siretart> in fact, there should be 2 fields, one for the url, and one with a SHA1 sum.
[09:51] <seb128> well, could be easy to write some tool getting the tarball, bzr getting the debian dir and building the package
[09:51] <dholbach> who's taking notes? :)
[09:51] <dholbach> great :-)
[09:51] <siretart> :)
[09:51] <siretart> but I'm still not convinced that we should shut down revu
[09:51] <LaserJock> we aren't going to do it right away though
[09:52] <dholbach> no we shouldn't, but we should put some efforts in trying it out and making it run smoothlessly
[09:52] <LaserJock> I think the bzr way is going to be really hard for new people at this point
[09:52] <seb128> siretart: do you thing many people review things on it?
[09:52] <siretart> I'd suggest that we try it out with some packages, and then discuss about the experiences with it
[09:52] <ajmitch> not until some of the bugs related to bzr & launchpad are fixed
[09:52] <giskard> https://wiki.ubuntu.com/NoMoreSourcePackages
[09:52] <ajmitch> siretart: we could always hack revu to put new packages into branches on launchpad
[09:52] <siretart> seb128: I ask the other way: do you think more ppl will review packages if it is a launchpad branch?
[09:52] <dholbach> We'll manage! Where's the old MOTU "We have the Power" team spirit?
[09:52] <seb128> siretart: I would for one
[09:53] <siretart> interesting
[09:53] <giskard> http://wiki.debian.org/BzrBuildpackage
[09:53] <LaserJock> dholbach: drowned in bugs, merges, and revus ;-)
[09:53] <dholbach> siretart: it's more about the collaboration getting the things and pieces together
[09:53] <ajmitch> dholbach: sitting on the floor in the corner :)
[09:53] <giskard> siretart, it's more easy to manage, ihmo.
[09:53] <crimsun_> one notable example would be say feisty's compiz, which kinda sat on revu
[09:53] <seb128> siretart: having to send a key annoyed me enough that I never registered on REVU
[09:54] <siretart> seb128: you are already in the keyring. since the beginning
[09:54] <seb128> crimsun_: I've uploaded 0.3.4 today using changes from the REVU package
[09:54] <siretart> seb128: I'm importing the lp group, you know?
[09:54] <seb128> siretart: I don't know how to log in then
[09:54] <siretart> that's indeed an issue. right
[09:54] <dholbach> Shall we move on to Merges and SRUs and 'etc.' :-) ?
[09:54] <ajmitch> lp group includes all -dev & -core-dev
[09:54] <ajmitch> dholbach: please
[09:54] <crimsun_> seb128: right, using that as an example of where LP branches would assist/encourage/speed
[09:54] <dholbach> sistpoty: your stage
[09:54] <ajmitch> dholbach: otherwise this'll go as long as a CC meeting :)
[09:54] <seb128> crimsun_: right :)
[09:55] <sistpoty> erm... let's move on to merges
[09:55] <ajmitch> merges - we're lagging
[09:55] <sistpoty> kinda
[09:55] <seb128> launchpad has the advantage then everybody is already using it
[09:55] <ajmitch> is MoM updating yet?
[09:55] <bddebian> Yes
[09:55] <ajmitch> oh good
[09:55] <seb128> and than most of main uploaders and people likely to review package use bzr or have no problem to use it
[09:55] <crimsun_> [it would be a good thing to bring up the more current one that imbrandon/laserjack hacked up] 
[09:55] <bddebian> I always fear doing others merges
[09:55] <ajmitch> 141 outstanding, 38 updated
[09:55] <crimsun_> [err, nevermind then?] 
[09:55] <sistpoty> bddebian: good point, that I wanted to talk about
[09:56] <sistpoty> actually, everyone following now? *g*
[09:56] <dholbach> + (4 outstanding, 2 updated) from multiverse
[09:56] <ajmitch> sistpoty: I think so :)
[09:56] <sistpoty> ok
[09:56] <bddebian> I starting hitting multivers ones but 90% of them are dholbach's ;-)
[09:56] <sistpoty> well, the current mom-page seems to enforce some kind of maintainership
[09:57] <sistpoty> which is a good thing, because we don't do work s.o. else is already doing
[09:57] <LaserJock> http://tiber.tauware.de/~laserjock/motutodo/universe.html
[09:57] <ajmitch> sistpoty: yes, I've had at least a couple of packages where I got no notification from others that they had done the work at the same time I had
[09:57] <sistpoty> but for merges s.th. really bad, because we don't move forward, and ppl. are getting stalled
[09:57] <bddebian> A bad thing though is 4 or 5 of my merges won't work and I have no way of "telling" anyone not to bother
[09:57] <LaserJock> http://tiber.tauware.de/~laserjock/motutodo/multiverse.html
[09:58] <sistpoty> hm... anyone a good idea to make this situation better?
[09:58] <LaserJock> yeah, use our Dapper system
[09:58] <dholbach> I think that writing a really short notice  la "I'm working on xyz merge." should solve the issue
[09:58] <dholbach> just go ahead, write a mail and do it
[09:58] <LaserJock> I just don't think that's very realisitc
[09:58] <minghua> this doesn't stop dup work
[09:58] <LaserJock> for Universe
[09:59] <dholbach> LaserJock: why?
[09:59] <sistpoty> imo that won't work, because either you wait for a reply or you might do duplicate work again
[09:59] <minghua> because the previous merger may already started merging him/herself
[09:59] <LaserJock> because a lot of it is done by people who won't respond promptly
[09:59] <dholbach> minghua: I think it's the best solution - we don't all work in the same room :)
[09:59] <minghua> and he/she has nobody to notify
[09:59] <superm1> why not just ask the previous merger if they are planning on doing it before you start?
[09:59] <ajmitch> superm1: blocked waiting on a reply
[09:59] <LaserJock> people shouldn't have to track down the previous merger
[09:59] <zorglu_> sistpoty: how frequently such duplication happen ?
[09:59] <bddebian> Quite a bit
[09:59] <sistpoty> before we had the dapper tool, I was bitten quite often
[10:00] <crimsun_> ok, this is going to clash somewhat, but I think we should make merging as non-blocking as possible
[10:00] <siretart> zorglu_: it did happen. I don't think there are clear numbers
[10:00] <bddebian> crimsun_: I agree
[10:00] <crimsun_> I've personally used the /msg approach and just gone ahead
[10:00] <LaserJock> but I think it's also preventing people from attempting merges in the first place
[10:00] <ajmitch> crimsun_: that's fine, assuming that the person hasn't done 95% of the package, and is offline for a day or so
[10:01] <bddebian> One problem I see is things like Wine though.  I did a merge of wine from Debian for Edgy, only to find out that we weren't syncing with Debian.
[10:01] <crimsun_> bddebian: is that fairly common or a corner case?
[10:01] <minghua> yeah, we should have a "completely-not-syncing-from-debian" list
[10:01] <dholbach> I suppose it's a very corner case.
[10:02] <ajmitch> two different needs that we have - to get them all done asap, and to not step on everyone's toes
[10:02] <bddebian> Hard to say but I've hit it with a few packages
[10:02] <LaserJock> we really honestly need a per package note area and a way to "lock" tasks
[10:02] <siretart> crimsun_: I think it is a corner case, but when it's happening, it is quite annoying
[10:02] <bddebian> All of the multimedia packages come to mind
[10:02] <siretart> can we perhaps mention the fact in the source package if a package exist in debian, but we take it from some other source?
[10:02] <sistpoty> well, we could as LaserJock pointed out reuse the dapper-tool. imo it worked quite well, but it was a little bit complicated
[10:03] <siretart> I'd again suggest to introduce a XS- field in debian/control for that
[10:03] <crimsun_> I agree with siretart
[10:03] <LaserJock> for what?
[10:03] <crimsun_> source that does not originate from Debian
[10:04] <sistpoty> sounds sane
[10:04] <siretart> but with a package existing with the same name in debian
[10:04] <siretart> shall we go by an X- field or by debian/README.Source?
[10:04] <crimsun_> the former seems more sane
[10:05] <sistpoty> but I guess we're getting a little bit off topic... how to solve the merge problem in a sane way?
[10:05] <dholbach> probably debian/README.Source doesn't set up dpkg-buildpackage that much? :-)
[10:05] <siretart> dholbach: thats right. it causes warnings for lintian/linda
[10:05] <dholbach> shall we move that discussion to the mailing list now that we have a few proposals?
[10:05] <crimsun_> is there any way we can currently use LP to leave notes per source package?
[10:05] <siretart> okay
[10:06] <dholbach> who's going to post?
[10:06] <sistpoty> dholbach: what discussion? about merges or x-field?
[10:06] <sistpoty> crimsun_: only via bug afict
[10:06] <dholbach> sistpoty: x-field, as it seems more 'resolved' than the process question
[10:06] <sistpoty> dholbach: ah, k... sure
[10:07] <ajmitch> so, freeze dates?
[10:07] <siretart> so, the 'best' proposal (AFAI can see) seems to be to do a ping to the previous merger via irc/jabber whatever, and don't wait for confirmation
[10:07] <siretart> right?
[10:07] <ajmitch> or will we keep talking about merges?
[10:07] <sistpoty> still merges ajmitch
[10:07] <siretart> ajmitch: I think we didn't come to any agreement. Up to now, I only have 'we talked about merges' in my notes :)
[10:08] <ajmitch> right :)
[10:08] <sistpoty> siretart: imo that's what we're doing right now, and its suboptimal imo
[10:08] <sistpoty> but I don't know the optimal solution :)
[10:08] <siretart> k
[10:08] <sistpoty> :(
[10:08] <sistpoty> even
[10:08] <LaserJock> at the very least we could file bugs
[10:08] <crimsun_> seems a bit heavyweight
[10:08] <bddebian> Don't we have enough bugs? :)
[10:09] <LaserJock> well, LP sucks, what can I say
[10:09] <LaserJock> :-)
[10:09] <crimsun_> I think using a wiki page, while inefficient, is lighter weight
[10:09] <sistpoty> bddebian: but you'd get karma *g*
[10:09] <bddebian> sistpoty: Hmm, good point ;-)
[10:09] <ajmitch> crimsun_: running a script to file a bug for a package, saying that we're merging it, isn't too overweight
[10:09] <LaserJock> crimsun_: and quickly gets outdated
[10:09] <dholbach> Ok, let's move that to the mailing list too, there's no point in brooding over the topic together when we have run more than an hour and a half an agenda left
[10:09] <crimsun_> ajmitch: ok, concur there.
[10:09] <sistpoty> well, I also don't really want to return to wiki pages...
[10:09] <LaserJock> virtually every time we've tried using wiki pages for workflow it just hasn't been very effective
[10:10] <minghua> let's discuss on list then
[10:10] <sistpoty> agreed
[10:10] <dholbach> we even have a thread for that already
[10:10] <crimsun_> ok, next point is deciding universe UVF/FF
[10:10] <crimsun_> cf. https://wiki.ubuntu.com/FeistyReleaseSchedule
[10:10] <sistpoty> crimsun_: did you want to say s.th. about SRU? (since you put that back in)?
[10:11] <crimsun_> sistpoty: that was mainly process and can be given to MC
[10:11] <dholbach> I asked Tollef who's doing the release management to add it to Beta Freeze, for some reason it's gone from the spec
[10:11] <dholbach> shall we discuss this on devel-discuss and CC Tollef in the discussion?
[10:11] <ajmitch> will we have the same freezes as for edgy?
[10:11] <dholbach> I'm happy to start the mail
[10:11] <ajmitch> where universe freeze == upstream version freeze for universe, no new packages
[10:11] <crimsun_> dholbach: that would be great.
[10:12] <dholbach> I suggested Beta Freeze for UniverseFreeze
[10:12] <ajmitch> and then a freeze a week or so from release, for all uploads
[10:12] <siretart> I'd propose to make a preliminary freeze date at the same date as main, and then reconsider the state of our universe
[10:12] <dholbach> we can all add pros and cons of different dates there
[10:12] <sistpoty> dholbach: it's already discussed. it's motu's responsibilities to make up dates
[10:12] <siretart> we cannot say now in what state debian will be short after its release
[10:12] <siretart> as we cannot predict when debian will release
[10:12] <dholbach> right
[10:12] <ajmitch> siretart: debian import freeze is in one week
[10:12] <ajmitch> so no autosyncs from then
[10:13] <siretart> ajmitch: why that early?
[10:13] <ajmitch> etch release
[10:13] <siretart> now I see it as well
[10:13] <dholbach> siretart: that's not ==UVF
[10:13] <ajmitch> no, but it does slow everything down a lot for universe
[10:13] <ajmitch> since we have to request every change after that
[10:13] <sistpoty> imo we could stay pretty much aligned to main dates, but have FF (affecting only new packages) later, so that we might be able to bring more in
[10:14] <siretart> dholbach: with having the largest portion of our packages in sync with debian, this is on the large scale the same, IMO
[10:14] <dholbach> sistpoty: I'm fine with that
[10:14] <siretart> ajmitch: right. I remember lucas doing some statistics about critical bugs missed by not doing autosyncs anymore
[10:15] <ajmitch> siretart: if we get lists of bugs fixed in debian, and not in ubuntu, it'll be easier
[10:15] <dholbach> everybody saw this: https://lists.ubuntu.com/archives/ubuntu-devel/2006-December/023034.html ?
[10:15] <LaserJock> we should have a list of RC bugs on Universe packages
[10:15] <ajmitch> dholbach: yes, if we can have something like that regularly
[10:15] <dholbach> ajmitch: I think that's the plan
[10:15] <ajmitch> with package versions
[10:16] <LaserJock> well, it needs to be usable
[10:16] <minghua> dholbach: yeah, but IMO that mail is too long to really help
[10:16] <dholbach> ajmitch: you can ask Keybuk for that
[10:16] <siretart> dholbach: I saw it, but I fail to see some explanation about that list
[10:16] <siretart> dholbach: how often will that list be updated? how exactly is this list calculated?
[10:16] <dholbach> siretart: it lists important fixed debian bugs since the "last time"
[10:16] <dholbach> siretart: I don't know
[10:17] <dholbach> it's Keybuk's black magic, you have to ask him
[10:17] <siretart> who did this at all? ;)
[10:17] <siretart> hm. he could really have been a bit more specific
[10:17] <dholbach> ok, let's move back to freeze dates
[10:17] <dholbach> everybody agreed we have the discussion on devel-discuss?
[10:17] <crimsun_> yes.
[10:17] <dholbach> ok cool
[10:17] <dholbach> next up: Plan the next REVU-day
[10:18] <ajmitch> next week?
[10:18] <LaserJock> hmm? shouldn't we discuss it on -motu first?
[10:18] <dholbach> will we manage to do it before christmas?
[10:18] <ajmitch> why not?
[10:18] <dholbach> LaserJock: it's fine to discuss it on -discuss
[10:18] <crimsun_> how about the same as hug day?
[10:18] <dholbach> crimsun_: will it clash?
[10:18] <sistpoty> why discuss the revu-day on -motu? we can do that right here *g*
[10:18] <dholbach> sistpoty: discuss freeze dates on -discuss
[10:19] <LaserJock> sistpoty: I meant Freeze dates
[10:19] <sistpoty> i know *g*
[10:19] <crimsun_> dholbach: I'm not convinced that "revuing" really detracts from bug triaging
[10:19] <crimsun_> perhaps it's my particular workflow, which I'm willing to admit
[10:19] <dholbach> crimsun_: it was a question - I'm fine with the idea
[10:19] <sistpoty> when is that day?
[10:19] <LaserJock> has REVU Days really worked?
[10:19] <crimsun_> dec 20
[10:19] <LaserJock> *have
[10:20] <dholbach> LaserJock: they have, and in any case we should pimp them some more
[10:20] <LaserJock> we should at least collect some statistics from the REVU Day that we can give in some sort of report
[10:20] <sistpoty> LaserJock: might be a good idea
[10:20] <dholbach> LaserJock: are you volunteering?
[10:21] <sistpoty> (I've always reviewed on other days then revu-days)
[10:21] <LaserJock> not sure
[10:21] <crimsun_> is dec 20th particularly bad for anyone?
[10:21] <dholbach> Ok, let's agree on the date first? all sufficiently happy with dec 20?
[10:21] <crimsun_> (I am.)
[10:21] <dholbach> I'm happy too
[10:22] <sistpoty> (well, it's under the week, so I'm home only after 20.00 *g*)
[10:22] <minghua> well, I am not really happy, but I don't usually REVU anyway
[10:22] <ajmitch> as usual
[10:22] <dholbach> Ok, let's go with 20th then - nobody stops you to review on other days :-)
[10:23] <dholbach> who writes an announce?
[10:23] <dholbach> going once
[10:23] <dholbach> going twice
[10:23] <crimsun_> we could even use dec 20th as a reporting date for say a 3-day revu sprint akin to BSP
[10:23] <dholbach> ok, I do it
[10:23] <dholbach> :)
[10:23] <dholbach> 3-day-revu-sprint!
[10:23] <dholbach> woah! :-)
[10:23] <bddebian> heh
[10:23] <sistpoty> omg! *g*
[10:24] <dholbach> if we can pimp it and keep up the REVU atmosphere and make that our christmas present to ubuntu and the motu hopefuls, why not
[10:24] <dholbach> who of us has a blog on planet who could also write about it?
[10:25] <siretart> sistpoty: I can arrange something ;)
[10:25] <dholbach> ok, so that's LaserJock, siretart and me?
[10:25] <dholbach> oh imbrandon too
[10:25] <crimsun_> and cbx33
[10:25] <sistpoty> siretart: well, I can arrange s.th. too. but I'm too lazy do set up a blog *g*
[10:25] <dholbach> ah right
[10:25] <dholbach> so everybody of us can pick a day and write a bit about it :-)
[10:25] <dholbach> that'd be so cool
[10:26] <siretart> ajmitch: no way. You are a motu rockstar like everyone else! *g*
[10:26] <ajmitch> siretart: I prefer the background, thanks
[10:26] <sistpoty> hehe
[10:26] <siretart> hehe
[10:26] <dholbach> Ok, who likes the 3-day-revu-sprint idea?
[10:26] <sistpoty> +1
[10:26] <crimsun_> I do. :)
[10:26] <dholbach> ROCK, let's do that - I write the announce
[10:26] <ajmitch> ok
[10:26] <ajmitch> MOTU SCHOOL!!
[10:26] <dholbach> next up: Check MOTU-school status (sistpoty) (if there's a session planned, please take over this point)
[10:27] <ajmitch> who wants it? :)
[10:27] <zorglu_> go flashy, make it an event :)
[10:27] <sistpoty> well, we could just do a session during the revu-sprint
[10:27] <ajmitch> it seems like the Ubuntu Open Week went pretty well
[10:27] <sistpoty> maybe some kind of q-a session?
[10:27] <siretart> sistpoty: that's a good idea
[10:27] <dholbach> let's brainstorm some session suggestions
[10:27] <ajmitch> I'm up for doing some session, but not until mid-january or so
[10:27] <nixternal> yes MOTU SCHOOL!!
[10:27] <dholbach>  * packaging libraries
[10:27] <dholbach>  * updating packages
[10:28] <sistpoty> I guess I could do some q&a-session during revu days, showing some common mistakes and how to fix them
[10:28] <dholbach> * regular(!) q-a sessions
[10:28] <nixternal>  * nixternal proofing packaing
[10:28] <siretart> * merging packages
[10:28] <dholbach>  * introduction to bzr
[10:28] <siretart> * importing packages to the bazaar
[10:28] <dholbach> hehe
[10:29] <crimsun_>  * universe SRU (-proposed/updates) and security errata (-security)
[10:29] <siretart> dholbach: that's different to your point!
[10:29] <sistpoty> * universe UVF-exceptions
[10:29] <ajmitch> * dealing with Debian
[10:29] <sistpoty> dealing with bddebian :P
[10:29] <dholbach> siretart: right, I just tought it was funny :)
[10:29] <nixternal> with respect to siretart's * merging packages, would it be possible to do a merge that doesn't require assistance (for the newer) and one that does require assistance due to errors?
[10:29] <minghua>  * read MoM outputs
[10:30] <bddebian> sistpoty: Thanks man :-)
[10:30] <dholbach> What a nice list we have there
[10:30] <minghua> uh... does that mean our meeting should end soon? :-P
[10:30] <sistpoty> well, we should try to find *one* next session soon imo
[10:30] <dholbach> I'll add them to te MOTU/School/Sessions list and write a follow up mail to MOTU so we can get cracking on it
[10:30] <siretart> nixternal: sure. do you think you could prepare such a session?
[10:30] <crimsun_> nixternal: that would be similar to what I went over with Fujitsu
[10:30] <dholbach> and think about the sessions over the holidays
[10:30] <nixternal> siretart: not i, i need to learn it, that's why i proposed it :)
[10:30] <dholbach> sistpoty: the qa session would be easiest to set up
[10:31] <dholbach> we can definitely make that one happen
[10:31] <nixternal> i tried one today and got a little confused with the C and C* issues
[10:31] <sistpoty> hm... as written above, I'd do one during revu-days
[10:31] <dholbach> sistpoty: nice
[10:31] <nixternal> crimsun_: cool, i am taking it that the session was logged?
[10:31] <crimsun_> nixternal: yes, it was the second one iirc
[10:31] <nixternal> cool..thanks
[10:32] <sistpoty> dholbach: maybe in the middle of them, or in the first evening... what do you think would be optimal?
[10:32] <dholbach> i'm travelling the evening on 21st, so if you want me, let's not do it then
[10:32] <dholbach> european evening that is
[10:32] <siretart> anything else for the meeting today?
[10:32] <dholbach> but pick anything else
[10:32] <sistpoty> dholbach: actually I was thinking of packaging q&a
[10:32] <dholbach> sistpoty: I know, but weren't we talking about doing it during the revu-days?
[10:33] <dholbach> it'd be good if I would announce it in the same mail
[10:33] <dholbach> sistpoty: let's decide that together and move on, ok?
[10:33] <sistpoty> dholbach: yes...
[10:33] <dholbach> ok
[10:33] <dholbach> next meeting's time
[10:33] <dholbach> what about 3rd week of Jan?
[10:34] <sistpoty> a little bit earlier?
[10:34] <dholbach> we should be all back from having holidays by then
[10:34] <ajmitch> 2nd week?
[10:34] <dholbach> ajmitch: me too, but after that I'll have a lot of stuff to catch up with
[10:34] <ajmitch> depends when the next TB meeting is, too
[10:34] <dholbach> but anyway, should be fine
[10:35] <sistpoty> ajmitch: next TB meeting is next week
[10:35] <crimsun_> Friday, Jan 12, 2007 20:00 UTC?
[10:35] <ajmitch> sistpoty: you're sure?
[10:35] <sistpoty> ajmitch: that says the fridge
[10:35] <dholbach> crimsun_: I like the date, but not the time
[10:35] <ajmitch> dholbach: later or earlier?
[10:35] <dholbach> earlier
[10:35] <crimsun_> 17:00 UTC?
[10:35] <ajmitch> 12:00 UTC?
[10:36] <sistpoty> damn, I'm usually most productive on fridays in uni *g*
[10:36] <dholbach> both is cool with me
[10:36] <crimsun_> I'm thinking of .au
[10:36] <dholbach> it's just that it's 22:36 for me now and it's been a long day :-)
[10:36] <crimsun_> is that really early for .au?
[10:36] <ajmitch> 12:00 UTC gives our australian MOTUs a chance
[10:36] <ajmitch> 1AM for me :)
[10:36] <sistpoty> yes, would be fair
[10:36] <minghua> probably the opinions of people who can't attend this meeting is more important?
[10:37] <ajmitch> but I wouldn't have work the next day
[10:37] <dholbach> minghua: good point
[10:37] <crimsun_> ok, I'm game for a tentative 12:00 UTC?
[10:37] <dholbach> we should alternate between meeting times
[10:37] <ajmitch> yep
[10:37] <sistpoty> +1
[10:37] <dholbach> but that's something we should discuss on the list
[10:37] <crimsun_> let's propose 12:00 UTC to the list and elicit input
[10:37] <sistpoty> but please, let's get two dates to vote for now
[10:37] <sistpoty> or thre
[10:37] <sistpoty> +e
[10:38] <sistpoty> otherwise nobody will come up with one
[10:38] <dholbach> ok, let's take it to the list then
[10:38] <ajmitch> so we're done?
[10:38] <dholbach> Anything else on the radar?
[10:38] <dholbach> Going once
[10:38] <dholbach> Going Twice
[10:38] <dholbach> Ok, Meeting adjourned :)
[10:38] <crimsun_> great. Thanks everyone!
[10:38] <mc44> will the MOTU council be approved at next weeks TB then?
[10:38] <ajmitch> thanks
[10:39] <dholbach> thanks everybody
[10:39] <ajmitch> mc44: iff there's a TB meeting next week
[10:39] <sistpoty> yay, thanks
[10:39] <sistpoty> the fridge mustn't lie *g*
[10:39] <ajmitch> oh it does
[10:39] <sistpoty> damn
[10:40] <sistpoty> and now finally a cigarette :)
[10:40] <ajmitch> it's up to the TB as to when they convene next
[10:40] <ajmitch> fridge is often a best-guess
[10:41] <bddebian> sistpoty: Good idea ;-)
[10:41] <sistpoty> hehe
[10:42] <siretart> sistpoty: have fun! :)
[10:42] <cbx33> I saw my name mentioned ;)
[10:43] <cbx33> eek bbl