=== yharrow [n=sysadmin@h-68-164-34-22.nycmny83.dynamic.covad.net] has joined #ubuntu-meeting === licio [n=licio@ubuntu/member/licio] has joined #ubuntu-meeting === Czessi [n=Czessi@dslb-088-073-021-021.pools.arcor-ip.net] has joined #ubuntu-meeting === ogra_ [n=ogra@p548AEDA3.dip.t-dialin.net] has joined #ubuntu-meeting === _czessi [n=Czessi@dslb-088-073-038-187.pools.arcor-ip.net] has joined #ubuntu-meeting === _czessi [n=Czessi@dslb-088-073-047-067.pools.arcor-ip.net] has joined #ubuntu-meeting === mc44 [n=mc44@unaffiliated/mc44] has left #ubuntu-meeting ["Exit,] === mdz [n=mdz@cpe-76-173-8-128.socal.res.rr.com] has joined #ubuntu-meeting === czessi_ [n=Czessi@dslb-088-073-020-142.pools.arcor-ip.net] has joined #ubuntu-meeting === ogra_ [n=ogra@p548AD448.dip.t-dialin.net] has joined #ubuntu-meeting === Mez [n=Mez@ubuntu/member/mez] has joined #ubuntu-meeting === j_ack [n=rudi@p508DB79B.dip0.t-ipconnect.de] has joined #ubuntu-meeting === freeflying_ [i=root@gobstopper.dreamhost.com] has joined #ubuntu-meeting === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #ubuntu-meeting === firephoto [n=tom@pool-71-115-214-25.spknwa.dsl-w.verizon.net] has joined #ubuntu-meeting === Burgwork [n=corey@S010600502c03205f.gv.shawcable.net] has joined #ubuntu-meeting === Burgundavia [n=corey@S010600502c03205f.gv.shawcable.net] has joined #ubuntu-meeting === beuno [n=martin@200.127.67.148] has joined #ubuntu-meeting === Burgundavia [n=corey@S010600502c03205f.gv.shawcable.net] has joined #ubuntu-meeting === slomo__ [n=slomo@pD954775A.dip0.t-ipconnect.de] has joined #ubuntu-meeting === mruiz [n=mruiz@ubuntu/member/mruiz] has joined #ubuntu-meeting === mruiz [n=mruiz@ubuntu/member/mruiz] has left #ubuntu-meeting ["Bye!"] === effie_jayx [n=valles@190.37.175.250] has joined #ubuntu-meeting === licio [n=licio@ubuntu/member/licio] has joined #ubuntu-meeting === gouki_ [n=gouki@bl4-198-120.dsl.telepac.pt] has joined #ubuntu-meeting === fernando_ [n=fernando@189.0.128.78] has joined #ubuntu-meeting === robitaille [n=daniel@ubuntu/member/robitaille] has joined #ubuntu-meeting === besonen_mobile [n=besonen_@71-220-225-182.eugn.qwest.net] has joined #ubuntu-meeting === rtg [n=rtg@rtg.theglobal.net] has joined #ubuntu-meeting === fernando [n=fernando@unaffiliated/musb] has joined #ubuntu-meeting === iGraphite [n=iGraphit@203-206-254-33.dyn.iinet.net.au] has joined #ubuntu-meeting === iGraphite [n=iGraphit@203-206-254-33.dyn.iinet.net.au] has left #ubuntu-meeting [] === j_ack [n=rudi@p508DB79B.dip0.t-ipconnect.de] has joined #ubuntu-meeting === asac [n=asac@debian/developer/asac] has joined #ubuntu-meeting === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #ubuntu-meeting === Hobbsee [n=Hobbsee@ubuntu/member/hobbsee] has joined #ubuntu-meeting [07:24] @schedule sydney [07:24] Schedule for Australia/Sydney: 16 Mar 21:00: MOTU Council | 18 Mar 02:00: Xubuntu | 20 Mar 02:00: Kernel Team | 20 Mar 10:00: IRC Operators | 21 Mar 05:00: Community Council | 21 Mar 23:00: Edubuntu [07:33] Hobbsee: going to join the MC meeting? [07:33] ajmitch: hrm...i could do that [07:34] argh! the library closes early tonight! [07:34] that's silly [07:34] yes. [07:34] everyone knows that the library is the most favoured place to be on a friday night === Hobbsee grins [07:34] of course! === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #ubuntu-meeting === freeflying [i=root@ubuntu/member/freeflying] has joined #ubuntu-meeting [07:54] @schedule us/chicago [07:54] @schedule us\chicago [07:54] @schedule chicago [07:54] @schedule [07:54] Schedule for America/Chicago: 16 Mar 05:00: MOTU Council | 17 Mar 10:00: Xubuntu | 19 Mar 10:00: Kernel Team | 19 Mar 18:00: IRC Operators | 20 Mar 13:00: Community Council | 21 Mar 07:00: Edubuntu [07:54] Schedule for Etc/UTC: 16 Mar 10:00: MOTU Council | 17 Mar 15:00: Xubuntu | 19 Mar 15:00: Kernel Team | 19 Mar 23:00: IRC Operators | 20 Mar 18:00: Community Council | 21 Mar 12:00: Edubuntu === Hobbsee [n=Hobbsee@ubuntu/member/hobbsee] has joined #ubuntu-meeting === Lure [n=lure@external-7.hermes.si] has joined #ubuntu-meeting === Sp4rKy [n=Sp4rKy@ubuntu/member/sp4rky] has joined #ubuntu-meeting === arualavi [n=Iva@67.Red-83-33-5.dynamicIP.rima-tde.net] has joined #ubuntu-meeting === arualavi [n=Iva@67.Red-83-33-5.dynamicIP.rima-tde.net] has joined #ubuntu-meeting === sky_walkie [n=hrdlo@193.85.244.121] has joined #ubuntu-meeting === zenrox [i=zenrox@pool-71-115-197-231.spknwa.dsl-w.verizon.net] has joined #ubuntu-meeting === dholbach [n=daniel@i59F70BDC.versanet.de] has joined #ubuntu-meeting === mvo [n=egon@p54A67F5B.dip.t-dialin.net] has joined #ubuntu-meeting === hjmf [n=hjmf@140.Red-217-125-227.dynamicIP.rima-tde.net] has joined #ubuntu-meeting === BackwardsDown [n=niels@5351BB29.cable.casema.nl] has joined #ubuntu-meeting === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #ubuntu-meeting === asac [n=asac@debian/developer/asac] has joined #ubuntu-meeting === finalbeta [n=finalbet@d54C689F7.access.telenet.be] has joined #ubuntu-meeting === pochu [n=pochu@ubuntu/member/pochu] has joined #ubuntu-meeting === gpocentek [n=gauvain@ubuntu/member/gloubiboulga] has joined #ubuntu-meeting === dennda [n=dennda@ubuntu/member/dennda] has joined #ubuntu-meeting === Lure [n=lure@external-7.hermes.si] has joined #ubuntu-meeting === firephoto [n=tom@pool-71-120-244-121.spknwa.dsl-w.verizon.net] has joined #ubuntu-meeting === ogra [n=ogra@ubuntu/member/ogra] has joined #ubuntu-meeting === lmanul [n=manu@194.230.53.149] has joined #ubuntu-meeting === sistpoty [n=sistpoty@ubuntu/member/sistpoty] has joined #ubuntu-meeting === finalbeta [n=finalbet@d54C689F7.access.telenet.be] has joined #ubuntu-meeting === ajmitch pokes Ubugtu [11:00] . o O { The bell tolls 11 times in Berlin... } === TheMuso [n=luke@ubuntu/member/themuso] has joined #ubuntu-meeting [11:01] hi everyone [11:01] does that mean we start without the smokers? :) [11:01] hehe [11:02] Let's start off then [11:02] I can live suppress my addiction for some time :P [11:02] s/live// [11:02] I added a comment on "Need some advise about becoming MOTU of the claws-mail program! (?TuxCrafter)" [11:02] because I think we can deal with this pretty easily === TheMuso vaguely remembers seeing that, [11:02] do we have anybody who'd like to be mentor for TuxCrafter and help him with getting things done? [11:02] TuxCrafter around? [11:03] Actually, I do remember seeing that. [11:03] dholbach: I'll take care of this [11:03] https://wiki.ubuntu.com/MOTU/Council/Meetings is the agenda for everybody who's around === ajmitch reloads the agenda [11:03] gpocentek: thank you very much [11:03] it's Xubuntu related, so... [11:03] yay, thanks [11:03] sistpoty and siretart wanted to discuss RFP bugs [11:04] well, the Candidates page is a little bit messy imo, could we use lp bugs for it? [11:04] s.th. like file against ubuntu, tag with RFP? [11:04] sounds good to me [11:04] whT is rfp? [11:04] I like the idea [11:04] TheMuso: request for package [11:04] Oh. === TheMuso practically never looks at that page. :) [11:04] (that way we could also link to debian rfps/itps) [11:05] once assigned, we could regularly ping the assignee and track how it's going [11:05] talk to laserjock about that please [11:05] ok, I'm going to announce the 'rfp' tag and the idea in general and link it from the bugs page [11:05] ajmitch: yep, good idea [11:05] he's been talking with the LP guys about what would best be used there === imbrandon returns [11:05] neat-o :) [11:05] move on? [11:05] in his role as LP contact :) [11:06] ah, the charter [11:06] ajmitch, rfp/itp ? [11:06] ok, I'll contact laserjock, and see what he's for us... ok? [11:06] imbrandon: both - once it's turned into an itp, the bug would just have an assignee [11:06] he has even [11:06] dholbach: re: 'rfp' idea: this also means that the 'Candidates' Page gets removed from the wiki, right? [11:06] dholbach, great [11:06] I'm happy to write some documentation on it [11:07] siretart: after a short while, I wouldn't want it to be just purged [11:07] ... just purged like that [11:07] siretart, well not removed, but turned more into an explination of how to file a rfp on LP ;) [11:07] dholbach: d'accord [11:07] also, we'd need to update Bugs/Responses [11:07] imbrandon: jupp [11:07] I'll take care of that [11:08] ok, moving on to the charter [11:08] maybe we could move to the last point... might make sense to have crimsun around for charter? [11:08] ok [11:08] this is really just a silly question from my side, as I get bounces quite often... can we do s.th. and what? [11:08] regarding ml bounces, I deactivated sending mail to doomrunner and mailed him about it (found a different address in LP) [11:09] usually that's only for people whose mail account is full, etc [11:09] ok, great :) [11:09] so after a few bounces you can take action on it === ajmitch doesn't moderate often because the mailman folder is low down in the mutt config :) [11:09] it's manual, but easy to deal with [11:09] ajmitch: pffffft :) === lmanul_ [n=manu@194.230.53.149] has joined #ubuntu-meeting [11:09] ok... I guess I'll look at the mailman thingy a little bit more in detail :) [11:09] too easy to forget about the mail piling up... [11:10] sistpoty: in the membership page, just click the 'nomail' thingie for that person and you're set [11:10] ah... cool. thx [11:11] ok, let's move on to KDE4 and the charter [11:11] ok [11:11] i personally feel that they both describe problems with "where does the MC stand" [11:11] ... in the MOTU world [11:11] yep [11:12] you might have read my latest response to the kde4 thread and I think we should have been quicker about escalaiting this to the TB [11:12] as the TB can do an ultimate decision and they approved the kde4 spec [11:12] Riddell: are you there? [11:12] well not exactly, this should be treated just as any other UVFe request, only in that instead of one person asking for the UVFe you have a group [11:12] abend [11:13] imbrandon: what do you mean by "not exactly"? [11:13] Riddell: :-) [11:13] hehe, just wanted to write that I also think we need some kind of escalation path, in case such problems occur later [11:13] in either case MC shouldent have a say in what is or isnt in the universe imho, only if to grant a uvfe or not [11:13] though motu-uvf gets its policy set by MC, etc [11:14] 3 of the team overlap with the MC anyway :) [11:14] right [11:14] what do you all think about moving the thread to ubuntu-devel and CC the TB? [11:14] well my big thing here is why is this set of packages gettign diffrent treatment than any other set of packages asking for a UVFe ? [11:14] I think that will resolve the issue quickly and we can all move on [11:14] imbrandon: why a different treatment? [11:15] imbrandon: it was asked for a general exception for it [11:15] we have't given out any general exceptions for a set of packages [11:15] well all this "todo" about it , i mean it boils down to if you need more information to grant or deny the uvfe then ask, if not move on [11:15] why all the TB etc [11:15] because this was initially presented as "we're doing this, unless the MC overrides" [11:16] confusion as to what team does what, etc [11:16] until now there was no decision yet, but people voiced their concerns/approval on a general exception [11:16] right, i'm not saying it was presented in the best way, but alot of things arent, just like any bug, there is a "more info" choice [11:16] ;) [11:16] for every other package, it's being done on a package-by-package basis, for each version [11:16] rather than a blanket exception for new packages & new versions [11:17] actually I'm not too happy to continue this thread... it imo caused enough harm already. and since we've been unable to come to a decision (I guess that's kinda our fault) I'd say that means we didn't object [11:17] so there's no precedent, hence the slow decision === ajmitch would think that the best way to get them useful is to stick them in universe & aggressively update in feisty-backports [11:18] agrees with ajmitch [11:18] to resolve the issue quickly, I'd suggest to contact the TB to get a final ACK and briefly mention the pros and cons that were pointed out, so we can move on [11:18] and voiced or not i know that is the intentions of those of us that work on them [11:19] dholbach: ok, with me [11:19] dholbach, see thats just it, can the MC not grant a UVFe? why ........ never mind, i guess only the "easy" decisions are ...... /me shushes [11:19] imbrandon: can you elaborate? [11:19] not without being so frank that i'm affraid to offend someone [11:20] move on, that's what we're all here for [11:20] go ahead anyway [11:20] imbrandon: better break toes know than kill persons later ;) [11:20] I'm sure we can make a rational decision and learn from the situation [11:20] Riddell: I guess you're quite busy atm, but what is your view on this? [11:20] ok, then imho MC should stepup and say yes or no, dont fall back to TB because its a hard decesion, if the awnser is no then we have to deal with it, if you need more info , then ask [11:21] imbrandon: that's hardly offensive :) [11:21] but falling to the TB i feel is a step back for the MC [11:21] not just this situation [11:21] my view is the same as that of the kubuntu council, the packages should go in. there's no point in having development packages any older than we have to and they have already solved some significant problems upstream by having them [11:21] the reason for falling back to the TB, so to speak, is to get a clear understanding of where our reponsibilities extend to [11:22] ie whether other teams would need to go through the policies set by the MC for anything in universe [11:22] in this case it was a preapproved spec that we'd be blocking if we didn't let it in [11:22] ajmitch, right, and as i said, the KC is asking for a UVFe , not telling since the spec went over time [11:23] but imho its justified [11:23] and falling back to TB is sane if we end up with conflicting interests from teams [11:23] imbrandon: right, but this is a different UVFe, up until release day :) [11:23] (since I guess we also need a clear escalation path) [11:23] ok [11:23] I agree with sistpoty - it'd be nice to hear what gpocentek and crimsun have to say [11:24] (crimsun might be a bit late) [11:24] well... [11:24] hopefully crimsun gets to the office (without a speeding ticket) [11:24] hehe [11:24] I'd be happy to see KDE4 in universe, but not really happy to see that it won't be maintained [11:24] and I really understand why the Kubuntu wants it [11:24] it will be maintained, through feisty-backports [11:25] c/ [11:25] gah [11:25] why does Kubuntu want to help the development of the next version of our desktop? [11:25] seems pretty obvious to me [11:25] do apps in -backports build against libs in -backports? [11:25] gpocentek: do you feel happy with letting the kubuntu guys do what they will with the KDE4 stuff in feisty, given that there's already some of it there? [11:25] i'm both on the KDE team and -backports and will personaly see that it is backported in a timely manner [11:25] dholbach, yes [11:25] good to know [11:26] imbrandon: that's great to hear [11:26] ajmitch: I'm sure they won't do "what they want" [11:26] (present, sorry for tardiness) [11:26] Riddell: "I really understand" [11:27] wb crimsun [11:27] gpocentek: that's what's being asked for - permission for new packages (kde4 apps), and updating the snapshots until release time [11:27] gpocentek: ooh, oops, my bad [11:27] crimsun: welcome [11:27] wb crimsun [11:28] we've gone with svn snapshot of Xfce until the last dapper development's day === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #ubuntu-meeting [11:28] that was pre-4.2? [11:29] shall we do a tentative vote and see where we stand? how would the result look in +1, +0,5, 0, -0,5 and -1 votes? [11:29] dholbach: you forgot complex numbers [11:29] you might also note too that feisty+1 will likely see a stable release of kde4 , this will GREATLY help the next version stableize [11:30] as we are pretty much one of the top KDE4 development platforms for upstream KDE [11:30] dholbach: sure === ajmitch puts in a +1 [11:30] imbrandon: that's interesting [11:30] I didn't realise kubuntu was so popular now in the developer community [11:31] in the kde developer community it is , 50/50 kubuntu/suse [11:31] it used to be a lot of mandrake, back in the day :) [11:31] :) [11:31] I'd vote with: +0,5 as I think that it's vaiuable and somewhat taken care of (through backports - bear in mind that not all people have activated them), but I'm not convinced that there will be enough manpower to feed those bugs upstream, to be really useful - also I think it's not good to have old delveopment snapshots [11:31] +1... because imbrandon will take care for backports (which was my main opposition), and because UVF-team seemed happy with it (at least from my memory of the thread) [11:31] (sorry, boken connection) [11:33] RE: KDE 4 snaps in feisty, precedence definitely has been set with Xfce for the past two stable releases in _main_. I've also already mailed about my feeling that the Kubuntu community wants these snapshots, and because they exist already in edgy, we really have no reason to not have such in feisty. Ultimately, however, I honestly don't feel the MC has the "powah" here to say yay or nay. [11:33] gpocentek: we were just conducting a tentative vote to see where we stand -- we're at +2,5 at the moment :) [11:33] crimsun: right, the kubuntu guys seem happy for now if MC approves it :) [11:34] crimsun: I tend to agree with your last point and we should discuss that in the next agenda point, when it comes to the charter. [11:34] dholbach: thanks [11:34] +1 from if the backports are available [11:34] I'm happy to say +1 for it based not on "geez, enough already" but on precedence. [11:34] imbrandon: (and I guess that's why we ultimately lagged behind on making a decision) [11:34] :) [11:35] (My fear what to see a development snapshot quite unusable and not updated in the repos) [11:35] Ok, shall we move on, announce the outcome? Any conditions? [11:35] I don't think we need further discussion now. [11:35] imbrandon: see, that was mostly painless ;) [11:35] hehe yes [11:36] no throwing chairs involved [11:36] i just dident wanna step on toes but knew you all could pull it off [11:36] part of the problem is what we'll discuss now [11:36] what responsibilities MC has [11:36] yep [11:37] what do you all think about having a weekly update on ubuntu-motu@ about how kde4 goes? what has been updated, what blockers are currently seen, etc? [11:37] (apparently I've traded one unstable connection for another, great. I'll lag momentarily.) [11:37] ok just to be clear , we have a UVFe for KDE4 snapshots / programs ? [11:37] I think that'd be only fair to know what's going on and where we might want to step in if things break to awfully [11:37] imbrandon: aiui, yes, since we know there's a defined set of programs there you'll be putting in [11:37] dholbach, sure, and i'll be happy to be the "contact" for that if you wish , between the MC and the KDE team [11:37] thanks [11:38] imbrandon: thanks a lot [11:38] we'll announce it like that and inform the TB about the decision [11:38] yay, thanks [11:38] moving on [11:38] what lessons can we learn from this? shall we do a quick brainstorming on that? === j_ack [n=rudi@p508D85DE.dip0.t-ipconnect.de] has joined #ubuntu-meeting [11:39] i'd like to hear imbrandon and Riddell on that, because their input is quite valuable as "other teams who deal with the MC" [11:39] we need to move faster on making a decision [11:39] while keeping everyone involved [11:39] * need clearer guidelines on what needs a MC decision and what not [11:40] ajmitch++ [11:40] * don't start voting too early [11:40] (sorry for that) [11:40] no problem - I'm very happy we're learning that fast [11:40] some MOTUs feel like they're cut out now [11:40] well on this feasico i have only 2 things i would have changed, imho , 1) the initial email might not have been in the form of a question but i would have requested that it was, or treated it as such ( e.g. asked for more info to grant/deny the UVFe ) and 2) .... [11:41] I think ultimately we need to be careful to not appear to decide _for_ MOTU as a whole but simply decide who becomes MOTU. [11:41] crimsun: right, that's a matter of whether we should be making these decisions or not, no? [11:42] It can be confusing as quite a few of us (MC) straddle teams. [11:42] ajmitch: right [11:42] tream other teams that come into your "domain" as any other person, it shouldent have been any diffrent that KC was asking or joe blow [11:42] yea [11:42] crimsun: that will leave the following problems: who could do this decisions then? how could decision be done in a timely matter? [11:42] I agree with crimsun there - the MC was envisioned as somebody being responsible for decisions, not making them as a clique - up until now we didn't do that many decisions and they've always been backed up by lots of MOTUs [11:43] imbrandon: how do you feel were you treated differently than joe blow? [11:43] even for the SRU policy vote, which was done in a MOTU meeting, some MOTUs felt like their votes wouldn't count [11:43] we should point that out in the charter [11:43] definitely [11:44] i dont think it was really, but i was just saying, you were worried weather it was KC saying yes or MC saying yes, it should have been turned arround right away in the MC's head that someone was asking for a UVFe , not someone was demanding one [11:44] In the future, we should move quickly to delegate to the appropriate team. It's kinda unfortunate at the present overlap, but that will change in the next release. In this instance, IMO MC should have said "oh, this is motu-uvf material, *handoff*". [11:44] imbrandon: I personally don't feel that it was a KC vs MC decision. I feel that the problems at hand were discussed quite rationally [11:45] e.g. if i came to the MC and said "i've decided i am granting a uvfe for apt-mirror because i maintain it" you would naturaly turn and ask "why" and explain the situation, not debate weatyher i had the "powa" todoso [11:45] imbrandon: I think there was confusion about whether the MC would have authority to say no [11:45] dholbach, i 100% agree [11:45] imbrandon: ok good :) [11:45] here they were , i mean leading upto here [11:45] just was an observation [11:45] not a ohh no, kinda thing [11:45] :) [11:45] :) [11:46] personally there seemed to be a lot of "gut reaction" mixed with rational argument === ajmitch is becoming too much like dholbach, scary [11:46] I propose to point out in the Charter that the MC is responsible for decisions and that anybody can track them down for deciding in a certain way, but that they're not making the decision - merely making sure that a decision is reached (if there's a dispute) [11:47] so we should try & keep as many decisions in the MOTU list & meeting as possible [11:47] that way people won't feel there's a clique who decides over them and blocks them - does that make sense? [11:47] at what point would the MC step in & make a decision? [11:47] right, the MOTU's as a whole [11:47] I concur there (to both Daniel and Andrew) [11:47] dholbach: it does make sens [11:48] eg we debated the kde stuff for a week or so [11:48] hm... I'm not quite sure if it works out... since motu meeting (the only instance we came to decisions before MC) are scheduled only every 3 weeks [11:48] we can step those up if needed [11:49] we should always be able to meet more frequently as necessary and certainly in urgent cases [11:49] but i dont see a whole lot of decisions needeing to be made imho [11:49] should we make it a MOTU meeting every 1,5 weeks and just make sure that there's a MC quorum if things really get out of hand? [11:49] making everything too democratic can slow things down a bit - see how GRs work in debian :) [11:49] and drop MC meetings [11:49] and tag agenda points as (POLICY) or something [11:49] no... imo we should make more clear when MC will step in/what's the place of mc === ajmitch doesn't think that every decision needs to be put before all the MOTUs [11:50] ajmitch: what do you mean by that? [11:50] retaining the ability to make minor decisions quickly is important [11:50] sistpoty, +1 , i only think the MC should step in where the MOTU's cant decide amongst themselfs , even on policy [11:51] I think it's good to have a MC quorum around, so it has the "sign off" effect and can inform the TB as the MC is supposed to [11:51] I'm not sure we need different meetings for that [11:51] in debian the DPL can make a number of decisions, delegations etc [11:51] and I think that future agendas will be quite short [11:51] but everyone can still vote by way of GRs [11:52] ok let me pint this out, the MOTU made decisions before and when a decision couldent be reached it was taken to the TB , the MC is only taking the TB spot in this senerio , not the whole of the MOTU [11:52] ajmitch: what do you propose? [11:52] well, I see it like that: MC should step in exactly where's need. if s.th. is working out already, it should not interfere. This would then mean that Motu meeting can do decisions on its own [11:52] sistpoty: agreed [11:52] if these are dumb... or if a decision needs to be done very quick, MC can jump in [11:52] do you think we need two "different" meetings? [11:52] dholbach: I mean things like team delegations can take awhile if it's put to nominations, everyone voting, etc [11:53] dholbach, no imho [11:53] OTOH, we need to be careful to not "cut off" any MOTU, so we're walking a thin line here. [11:54] crimsun: can you explain? [11:54] jumping into a decision too quickly, not getting input from others [11:54] right === ajmitch would hope that more MOTUs could attend the MC meetings [11:54] as Andrew stated [11:54] unless we want to scrap them & have more MOTU meetings [11:55] i think only one meeting is nessesary but a quorum of MC members is needed at any MOTU meeting incase decision pop up [11:55] we do need to talk about some MC-specific things, like how we're going with the new MOTU applications :) [11:56] I propose: having motu meetings every two weeks, everybody can vote (also on mailing lists if that's appropriate) and if there are policy decisions together with a MC quorum we can present it to the TB === mc44 [n=mc44@unaffiliated/mc44] has joined #ubuntu-meeting [11:56] dholbach: sounds good === fernando [n=fernando@unaffiliated/musb] has joined #ubuntu-meeting [11:56] Although not MC, I like the sound of that. [11:56] /me agrees with dholbach [11:56] we'll need to rotate the meeting times a bit [11:57] 3 of the MC members are (nominally) in european timezones :) [11:57] dholbach: as a way of removing MC meetings altogether? [11:57] moin all [11:57] crimsun: yes, because my impression is that the topics are roughly the same in those meetings anyway [11:57] "the same" [11:58] well, I still don't see the need why we would need MC quorum. Imo this sounds to me like taking away decisions from motu. [11:58] gets more input into MC stuff from the rest of the MOTU crowd [11:58] sistpoty: only in the decisions we present to the TB - like BIG changes [11:58] sistpoty: right, I agree there. In MOTU meetings we are not MC but simply MOTU, IMO. [11:59] crimsun: exactly [11:59] so in the case that all of the MC members vote one way, while the rest of the MOTUs vote another way..? [11:59] (not that one can "simply" be MOTU, but ... semantics) [11:59] majority rules, right? [11:59] can we agree that there are certain decisions that need "signing off" or need somebody who's "responsible"? [11:59] ajmitch: yep [11:59] ajmitch: right, we should still be accountable to our body, so to speak [11:59] sistpoty: ok, just wanted to make that clear :) [12:00] dholbach: no === jenda [n=jenda@ubuntu/member/jenda] has joined #ubuntu-meeting [12:00] ok, maybe I meant being "accountable to our body" :) [12:00] dholbach: I'd formulate it the other way round... if big decisions are really getting to be hosed, MC should *then* intervine, but not generally be needed if things work out [12:01] was that english? [12:01] dholbach: the one that I can think of immediately is deciding who becomes MOTU. Beyond that, I really don't see our entity "intruding." [12:01] when do you think there needs to be a MC quorum? [12:01] sistpoty, +5 [12:01] crimsun, +25 [12:01] ok, that makes sense and is fine with me [12:02] we're getting quite good at formulating it the right way :) [12:02] hehe [12:02] ok, do you think the TB will agree? [12:02] or is the TB expecting the MC to make decisions? [12:03] can somebody try to sum up the proposal? [12:03] AFAIK the TB has only delegated to MC the approval of new MOTU [12:03] from what i recall in UDS , the TB is only expecting the laod to be off them generaly, so if we wouldent have taken it to the TB before then the MC shouldent be there [12:03] e.g. only new members [12:04] or "hard decisions that the motus cant agree on after much much debate" [12:04] thats it [12:04] dholbach: I can try to do it [12:04] ok [12:05] ie kinda what i was getting at a while ago that the KDE4 thing was a motu-uvf decision not a MC one [12:05] just as an example [12:05] proposal: that all MOTUs vote on issues, the MC members having the same status as any other MOTU, with meetings being held every two weeks, replacing the 3 weekly cycle of MOTU/MC meetings [12:05] and that if decisions are not being reached, then the MC steps in & makes a decision where needed [12:05] what did I miss from that? :) === Tonio_ [n=tonio@205.207.103-84.rev.gaoland.net] has joined #ubuntu-meeting [12:06] ajmitch, looks like you have it imho [12:06] yep [12:06] I would amend the last bit to be "if decisions are not being reached in a timely fashion" where timely fashion is clearly stated [12:06] to me it sounds quite accurate [12:07] days? 1 week? [12:07] or within the context of an irc meeting? [12:07] or s/timely fassion/MOTU's bring it to the MC/ [12:07] that always depends on all the facts being on the table [12:07] ? [12:07] imbrandon: sounds sane [12:08] we probably need to relax it a bit over our own 48 hrs [12:08] and since we don't well know that all facts have been presented... [12:08] yeah [12:08] 1 week would seem to drag. Does 3 days (72 hours) sound like a reasonable compromise? [12:08] that and some MOTU's arent on for days at a time, even though they may be active [12:08] crimsun: 3 days is fine with me [12:09] (sorry guys, I have to leave) [12:09] see ya gauvain [12:09] cya gpocentek [12:09] bye gpocentek, thanks for helping out [12:09] bye gpocentek [12:09] if we can wait 7 days for a package in -proposed , i think we can wait 7 days for MOTU input on a topic ( givein that both are in place for the same reason, to give everyone a chance to givce input ) [12:10] ok, let's add something like "the MC has been called for a vote and a clear proposal has been made" [12:10] I thought you mean about MC decisions now? [12:10] that will make it a lot easier [12:10] dholbach++ [12:10] dholbach ++ [12:11] yes, the distinction is necessary, and I concur [12:11] ok, let's add that to the charter [12:11] I'm quite happy with how quickly we resolved that and that we could all agree on it [12:11] ok guys i know i'm non-MC but i must run ( just FYI ) back in ~45 minutes [12:12] feel all patted on the back :) [12:12] hm... I'm not sure if it works out... sorry. let's try to replay the kde4 question how it would have ideally happened with the new charter, shall we? [12:12] sistpoty, motu-uvf would ahve decided and MC would have never been involved, with this charter [12:12] sistpoty: we probably would have called for a vote right about the 1-wk mark [12:13] crimsun: so that would have been 2 days ago [12:13] in an ideal world uploads wouldn't just have happened [12:13] but that we don't have control over [12:14] hm... actually I'm not quite sure who would have made what decision with the current proposal. is anyone else feeling this way? [12:15] because I think we should try to make that clear [12:15] sistpoty: KDE 4 should have been a motu-uvf decision [12:15] with the current proposal, it would have been up to motu-uvf - but there's nothing about how long a team like -uvf could take to make a decision [12:16] I think we all became more concious of whose responsibility what is - nobody would expect a certain team to do a decision and maybe things wouldn't be in limbo [12:16] ok... so Riddell would have asked, MC would have stayed quiet and motu-uvf have come up with a decision? [12:16] and in case there weren't a reaction from motu-uvf, MC would ping them, right? [12:17] yep [12:17] that sounds good to me [12:17] yes [12:17] that would also cover things like that xgl update [12:17] and if this still won't lead to a decision in a timely manner, MC steps in and makes one. agreed? [12:17] that sounds sane [12:17] great [12:18] ok, I guess I understand the notion of it now :) [12:18] ok, for other timely decisions - we have 2 weeks to make decisions on new MOTUs [12:18] I think Lutin's application is almost 2 weeks old [12:19] good point [12:19] is the timely decision thing in the charter for that? [12:19] not yet I believe... [12:19] since we should really call for votes in the last 2 days or so if it stretches out that long [12:20] what do you think about not letting such mails unanswered for more 24h? so one of us will either a) ask a question or b) step to do a vote [12:20] I think I'm going in invoke (to myself) the sabdfl's sentiment here regarding MOTU approval (back when TB was still approving MOTU), and that is we should give applicants the benefit of the doubt. [12:21] not quite sure actually... I didn't make up my mind on one day but also didn't have an idea on the same day what to ask === ajmitch usually doesn't have bright ideas of what to ask & reads the conversation [12:21] but I like ajmitch's proposal === Hobbsee [n=Hobbsee@ubuntu/member/hobbsee] has joined #ubuntu-meeting === sistpoty often asks around on #ubuntu-motu what other motus think [12:22] dholbach: I'm a bit uncomfortable with saying someone _must_ respond to email in 24 hrs [12:22] I was just trying to make some sort of commitment [12:22] I don't think it's the best proposal we can come up with either. [12:22]