=== asac_ is now known as asac === doko_ is now known as doko [11:59] * persia collects a gavel, and bangs it repeatedly === mcasadevall is now known as NCommander [11:59] #startmeeting [11:59] Meeting started at 05:59. The chair is NCommander. [11:59] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [11:59] * Hobbsee throws jelly beans at persia [11:59] NCommander has volunteered to chair the meeting. [11:59] * NCommander nods [11:59] Do we have a volunteer to take minutes? [12:00] OK. I'll do minutes. [12:00] * persia hands the gavel to NCommander [12:00] * NCommander eats it [12:00] What's the first topic of discussion [12:00] * NCommander is having trouble pulling up the wiki and the agenda [12:00] * persia notes that the chair might find the agenda at https://wiki.ubuntu.com/MOTU/Meetings useful [12:01] No, I know [12:01] the wiki was just timing out for me [12:01] Oh. I'm up first, in association with ScottK, to talk about https://wiki.ubuntu.com/MOTU/Decisions [12:01] Then comes LaserJock and I to talk about wnpp for Ubuntu. [12:01] Then it's AOB. [12:02] [TOPIC] MOTU Decisions [12:02] New Topic: MOTU Decisions [12:02] * NCommander gives the floor to persia [12:02] [LINK] https://wiki.ubuntu.com/MOTU/Decisions [12:02] LINK received: https://wiki.ubuntu.com/MOTU/Decisions [12:03] So, we've been using a new decision system for the past couple months. [12:03] ScottK has documented it at the link above. [12:03] When we established it, we did so on a provisional basis, to determine how it worked for us. [12:04] So, the question is: how does it work for us? Do we want to return to rule-by-those-who-attend-MOTU-Meetings? Do we want to keep this long-term? [12:04] One item of note is that we've not had MOTU Meetings in a while. It's probably worth discussing whether that's positive, negative, or a side effect of September and October. [12:04] well, how much success have we had with this new system? [12:04] My two cents on the matter is that when things go the list, it often seems to stagment [12:05] Hobbsee, We took one decision with it. [12:05] I thought we took more than just one. [12:05] I think the procedure has to be faster for trivial decisions [12:05] Define trivial decisions [12:06] mok0, So something like taking decisions in the meeting if it seems trivial and appointing a judge for the next fortnight if it's not? [12:06] NCommander: day-to-day decisions that everyone would agree on [12:06] persia: yes [12:06] I would agree. With things like policy changes, constitution drafting, etc, we should use the current system [12:07] But for trival day to day matters, I think the meetings is a good place for it [12:07] And simple action items, announcements, doc changes, etc. would be decided in a MOTU Meeting? [12:07] persia: yes [12:07] Sounds about right [12:07] Any dissent? [12:08] None here [12:08] * Hobbsee raises hand [12:08] MOTU meetings still don't ahve high turnout at all [12:08] their frequency means that I suspect any decision for there takes even longer to make [12:08] That's true. Do you think they'll have higher turnout if there's some discussion and decisions taken? [12:08] Perhaps the conditions could be even tighter: only if there is not consensus at the meeting, the elaborate procedure would be used [12:09] mok0, For small attendance, I'd suggest that even in some cases where there is consensus we should use the elaborate procedure, unless we decide to not use it at all. [12:09] If an action from a meeting is disagreed upon, then it will get discussioned when the meeting notes are published [12:09] persia: sounds about right. [12:10] persia: which then adds more time. [12:10] Generally speaking, we can decide an issue in a meeting, and if there is no dissent on the list, it should become policy [12:10] I am concerned that meetings will be reduced to a formality, which will impede our ability to act [12:10] Hobbsee, Well, yeah. I'm not a fan of time, but your point about attendance is a good one. [12:10] mok0, I think that's where we are now, and I think that's why nobody attends most meetings. [12:11] Well, it seems for me we've had less and less people showing up for these things [12:11] Perhaps we could simply set a lower limit on acceptable attendance for the meeting to be able to decide stuff [12:11] When I first came, we used to have a good user base [12:11] persia: based on the recent consistently low attendance, i feel that anything along the lines of "propose something at a meeting, then do the list process" is just going to take extra time - the time in between when the issue is raised, and the meeting is held [12:11] mok0, we have four people active at this meeting .... [12:11] + any deferrals, due to almost no one turning up [12:11] NCommander: out of what, 80? [12:12] Hobbsee, I see what you're saying. [12:12] NCommander: I'm now also here, finally (though I'm not a MOTU) [12:12] persia: and I don't see that as being simpler at all. [12:12] Hobbsee, well, we've personally discussed the issue of "active MOTU" before, but another time another place [12:12] persia: I agree with your general logic, though - if the meetings were actually better attended. [12:12] Hobbsee, How I'm understanding mok0's proposal is different: that one can raise something on the ML or the list, but that a decision is taken in the ML if trivial, or the longer procedure is continued if non-trivial. [12:12] Wait [12:12] Hold on, why don't we address the bigger problem [12:13] I have not been good at showing up. But democracy is about participation, so I can't complain if decisions were made that I didn't like [12:13] Why is attendence at the meetings so poor [12:13] NCommander: maybe a lot still think it's only for MOTUs? [12:13] Well, part of that is announcements. We need someone who can count days to volunteer to send announcements. [12:13] * persia is notoriously bad at that [12:13] sebner, I attended these before I was an MOTU, and we've had other ones do it [12:13] persia, we need a meeting bot :-) [12:13] persia: a cron script? [12:13] NCommander: a lot of the time, it appears that MOTU are bad at deciding things - and often meetings such as this are filled with waffle / discussion [12:14] NCommander: there is/was one O_o [12:14] mok0, Sure. Do you want to implement/host it? [12:14] a lot of people seem to not care one way or the other [12:14] Well, we cite 80 MOTUs, but how many of those are seriously active? [12:14] persia: yes [12:14] mok0, Thank you. [12:14] NCommander: Half. Ish. [12:14] I'd say even less [12:14] NCommander: maybe 30 [12:14] You can't give a hard answer. [12:14] RIght [12:15] Peoples time constraints may change on a week to week basis [12:15] The general way is to wait until auto expire,hmm? [12:15] Well, maybe we need a better way to set meeting times [12:15] sebner, No. Some people choose to leave. [12:15] sebner: "Now, beg" [12:15] I missed the last two because they are so freaking inconvenient [12:15] (To be extended) [12:15] NCommander, The trick is that we're all over the world. Every time is bad for most of us. [12:16] persia: some [12:16] s/most/some/ [12:16] * StevenK high fives sebner [12:16] * sebner high fives StevenK back =) [12:16] persia, right, but it just seems to me the times are a little arbitrarily [12:16] Fine. Some. [12:16] NCommander, Oh, completely. I picked them because they are round numbers. [12:16] Maybe if we regulate times to periods where a large group of MOTU is online, we'd get better turnouts [12:17] Nobody has ever made a serious effort to change them since I picked them. [12:17] (this has been a long time now, since before I was MOTU) [12:17] Well, looking at the MOTU map [12:17] NCommander: good idea... [12:17] Its largely three chunks of time periods. THose in Austrilian/Japnese team [12:17] Those in European time [12:17] And those in American time zones [12:18] What time is it now in Aussie? [12:18] Moderated by the fact that some people have time in the day, and some in the evenings. [12:18] But this is something we can't change as long as we want a meeting "together" [12:18] mok0: 11:28pm [12:18] It's between 20:18 and 23:18 in Australia. [12:18] (aest, anyway) [12:18] sebner, and mok0 where are you based [12:18] Europe [12:19] HRm [12:19] * sebner high fives mok0 [12:19] ^^ [12:19] I think we need to bring this to the list, and work out periods groups of people are most online [12:19] And then cycle the time for the meetings [12:19] NCommander: europe, 01:19 pm [12:19] One time favoring americans, then the next one, favoring Europe, and again favoring the Austraillians [12:19] It might help get better turnout [12:19] NCommander: meetings have to actually be a good use of time for people to come to, though. [12:20] Its pointless to have a meeting if no one can attend [12:20] NCommander: you got that right [12:20] * NCommander wonders if we're approaching a catch-22 [12:20] That was loosely what I was shooting for with the three current times. [12:21] I haven't really seen anyone complaining about the times. We all know that it is inherently difficult [12:21] Well, the Pacific is wide. Wouldn't be bad to move 04:00 UTC to 06:00 UTC, I suspect. [12:21] persia: would be better for europe, though I still sleep at that time :P [12:22] The agenda is know before the meeting, so if you have something you REALLY want to say, you can do it before the meeting [12:22] persia, correct me if I'm wrong, but you have staff privilleges in ~motu. I would recommend creating a poll with various times in UTC, and we could work out what times are best available for people [12:22] sebner, And not terribly worse for americas I think. [12:22] persia: yep [12:22] NCommander, That's been tried. It was never successful. I can do that, but I think it's better to just agree on some, using either decision process. [12:22] NCommander: Allow me to hypothesize that the results will cluster in three groups :-) [12:23] mok0, no that I know, but we can use the average of those three clusters to work out the best times for the majorities [12:23] I know with Kubuntu [12:23] * sebner is wondering how other world wide communities work on that problem [12:23] When we decide to have a meeting, we poll people who are online, and then use a website to determine the common time periods [12:23] We don't schedule our meeting too far in advance [12:23] I *really* don't like that suggestion. [12:24] Most of us are awake at least 16 hours a day, so at any given time we should be able to get 2/3 of all MOTUs to participate [12:24] Last time we did that, we didn't have a MOTU Meeting for two months. [12:24] persia, no, I'm just saying how Kubuntu does it [12:24] With Xubuntu, our meetings usually decided upon happening five minutes before we did them [12:24] Yes, I'm just stating opposition. [12:24] mok0: I sleep at least 10 hours per day ^^ [12:24] sebner: you are awake now, right? [12:24] sebner, Don't worry. There are others who make up your average. [12:24] mok0: it's midday ;) [12:25] persia: heh, sure [12:25] Now if we decide to adjust the times, we need to decide what these meetings are for [12:26] At this meeting, we have people from Australia, Europe, and US(?) [12:26] mok0: I think we have the same time zone \o/ [12:26] mok0, Yes. [12:26] Its been somewhat -EUNDEFINED in purpose since the change in voting [12:26] sebner: we are [12:26] mok0, its 7:26 my time EST [12:26] cool =) [12:27] I think we have two distinct but overlapping issues. How to improve member meeting attendence, and futhermore, what, if anything these meetings are for if we stay with the current voting system [12:27] So 13:UTC would make it more convenient for you, but less convenient for Hobbsee [12:28] * Hobbsee doesnt' really mind [12:28] not like i add much to the meetings anyway :) [12:28] Well, with the current system, we're supposed to discuss issues on the ML at the meeting, and appoint judges, but we haven't done that, despite many discussions that haven't reached useful conclusion. [12:28] Hobbsee: we like to have you around :-) [12:28] persia, I disagree [12:28] persia, the SRU policy was worked out mostly through meetings, even if we didn't completely conclude it here [12:29] er, keyteam [12:29] The biggest problem is these meetings are just a tad open ended. When we set something must be done, we made great progress during the KeyTeam discussion [12:29] NCommander, Right. I'm talking about the debdiffs discussion, the REVU Upload permissions discussion, the upstream contributions discussion, etc. [12:30] WIth the old system, those would have been MOTU Meeting topics. With the new system they are ML topics, but haven't been coming here to get a judge. [12:30] The only solution is to keep discussing until consensus is reached [12:30] Well, we don't need complete consensus, just rough consensus. [12:30] Sure [12:30] Personally, I think these issues should be decided and discussed here, post it to the list [12:31] I feel that most of us are fairly like minded on a lot of issues (i.e., 6-7 people is a good sample size for 30-40 active MOTU) [12:31] OK. It's getting on, and I've other topics. [12:31] Ok, I guess we're tabling the "Do we like the new method" discussion :-P! [12:32] Summary on this discussion? [12:32] Well, I'm not wanting to table it, so much as I think we've covered a lot of it. [12:32] half an over is already over =) [12:32] To me it sounds like most people agree with mok0, but that attendance is a concern, and that we have to balance that when taking decisions. [12:33] We could comprise [12:33] How about MOTU meetings can decide on trival issues [12:33] But allow a good grace period for people to object on the list [12:33] Look, there is no rule saying we can't revise a decision at a later time [12:33] Or just allow disputed decisions to be rediscussed. [12:33] If there is an objection, the change is suspended until a comprise can be made on the list, or the objection is removed. [12:34] * NCommander thinks we all just said the same thing [12:34] Right [12:34] mok0, Would you be willing to write up your proposal and judge consensus on the ML? [12:34] sure [12:34] [ACTION] mok0 to write up MOTU meeting decision policy [12:34] ACTION received: mok0 to write up MOTU meeting decision policy [12:35] [TOPIC]Discuss usefulness of a wnpp package for use with Ubuntu ITPs [12:35] New Topic: Discuss usefulness of a wnpp package for use with Ubuntu ITPs [12:35] * NCommander points to persia [12:35] OK. So LaserJock suggested that Ubuntu ought have a wnpp package, but has very limited time availability, so I'm presenting. [12:36] I personally don't see the point [12:36] The idea would be to move all the needs-packaging bugs against wnpp as an aid to triaging, and to more closely align with Debian, who uses the fake wnpp package for such things. [12:36] All needs-packaging bugs submitted have the needs-packaging tag [12:36] Which serves the same purpose [12:37] * Hobbsee thought the proposal was to put them on brainstorm [12:37] persia: benefits? [12:37] * NCommander thinks brainstorm is a worse idea [12:37] * sebner agrees [12:37] The primary advantages are that 1) it reduces noise in the bugs-without-a-package set, which helps bugsquad, 2) it makes it easier for automated systems to link bugs between Malone and the BTS, and 3) It helps build shared terminology, which may increase packages uploaded to Debian. [12:38] As an example, it would be convenient to be able to do a quick search for "bugs not fixed upstream" on wnpp, which would show targets for adoption and introduction to Debian. [12:38] Are the LP developers willing to implement such a system? [12:39] Hobbsee, This was proposed, but that means *less* tracking, and less coordination. To me it's tantamount to saying "We don't actually care about these, and are trying to ignore them". [12:39] sounds reasonable [12:39] NCommander, Dunno. I'm not going to ask LP about fake packages unless MOTU wants it. [12:39] That said, if LP can't do it, uploading a very small fake package isn't hard. [12:40] I personally don't see a lot of point in doing it. [12:40] persia: what would happen to the existing needs-packaging bugs? deleted? moved? remain? [12:40] sebner, we can move them to a package easily enough [12:40] NCommander: there are tons of them though [12:41] sebner, they're all tagged needs-packaging, a LP admin can kick the DB if needs be [12:41] NCommander: ok sound good [12:41] sebner, But the bugsquad will be *very* happy to help, since they currently have to ignore them on a daily basis, and it makes it harder for them to do their work. [12:41] persia, can't you hid bugs tagged? [12:41] NCommander, Not easily. [12:41] How will it work with linking to Debian ITP bugs? [12:41] Well, two other points [12:42] Why not simply have a project [12:42] mok0, bugs against package "wnpp" in Ubuntu would link against bugs against package "wnpp" in Debian. [12:42] i.e. like Ubuntu Backporters [12:42] They're out of the way for instance === thekorn_ is now known as thekorn [12:42] Because people file bugs against "Ubuntu" for them now, and most of the needs-packaging bugs aren't filed by developers. [12:42] persia: but that wouldn't be really useful, because both have hundreds of bugs [12:42] persia, I also don't know the usefulness of linking against ITPs [12:42] A *lot* of ITPs get filed and then just sit there [12:43] NCommander: keeping track of information is never bad [12:43] mok0, Well, it's useful for statistical purposes, but I agree it's not as useful as it is for many packages. [12:43] In addition, if we're going to track against ITPs, it might be easier to just get the package to go into Debian [12:43] We just need a DD or two who is willing to sponsor uploads on a regular basis [12:43] NCommander: that is not a bad idea [12:44] NCommander, The point of linking is that the bugtrackers can automatically identify when an Ubuntu bug is closed in Debian, or when a candidate package for a Debian bug is available in Ubuntu. [12:44] The problem with getting an upload monkey is that someone has to be the maintainer. [12:44] NCommander: nice idea but you know, we have DD's around but debian mentors still show a lot packages by ubuntu that are around for months [12:44] sebner, unlike REVU, you actually have to kick people to look at your packages at mentors [12:45] persia, Maintainer: Ubuntu MOTU Team [12:45] :-P [12:45] The icedove and iceape packages in Debian are Maintainer: Ubuntu Mozilla Team [12:45] NCommander: sure but in general there are also packages by MOTUs so DD that also work in Ubuntu could upload them without problems [12:45] NCommander, Well, not unless that gets organised as a Debian maintainer, which is a larger issue. [12:45] If we were able to channel new packages via Debian it would not be a lot of extra work up front [12:45] persia, organized as a Debian maintainer? [12:46] NCommander, consensus in both Debian and Ubuntu that it makes sense. [12:46] Well, Debian has Debian Maintainer status [12:46] That's a side issue. [12:46] no I mean [12:46] It might be worth talking with the DPL if they are willing to look towards increased combilation between Ubuntu and Debian w.r.t. to new packages [12:47] Anyway, let's defer the details of how we might integrate with Debian if we adopted the use of wnpp, and talk about whether we want to adopt the use of wnpp. [12:47] If the packages are also listed day zero NMUable, you usually get help from the QA team [12:48] Isn't it better to set up a specific Project on LP, call WNPP? [12:48] called [12:48] I think we need to sitdown with the DPL or some one of authority on Debian and see if we can find a good common ground, since -0ubuntuX packages with no Debian version just increase our burdens [12:48] It seems to me that "pseudopackages" are not a great thing to add to LP [12:48] mok0, There's no way to shift bugs between distrotasks and project tasks, so that ends up with lots of "Invalid" which confuses users. [12:49] persia, usability bug in Launchpad :-) [12:49] wgrant, ^ [12:49] ah. There is no such thing as a "friend" project ;-) [12:49] * persia doesn't mind putting together a real package documenting the Ubuntu new packages procedure and calling it "wnpp" if LP doesn't already do pseudopackages [12:49] Long-standing bug which isn't going to be fixed for a while, yes. [12:49] NCommander, Yes, but it's not going to be fixed any time soon. [12:49] Wow, that synced well in the middle. [12:50] LP won't let you assign a bug to a package which isn't published anywhere in the distro. [12:50] So it needs to be a real package, or have a hack in RF. [12:50] persia: would you be able to link from a specific ITP in the wnpp package to the equivalent one in BTS? [12:50] mok0, Yes. [12:51] so [12:51] What is our action on this one [12:51] wgrant, Thanks for the clarification. I'll probably have to chat with some people to determine if an Ubuntu-local wnpp doc package would be acceptable then. [12:51] [ACTION]persia to determine if a wnpp package is acceptable [12:51] ACTION received: persia to determine if a wnpp package is acceptable [12:52] * mok0 still thinks a project is the logical place to put this. If it doesn't currently allow us to exchange tasks, that shoulld be fixed., it should be made to work [12:52] s/package/project/ ? [12:52] Does that mean there's insufficient objection that I should proceed? [12:52] StevenK, No, package. LP bug. [12:52] persia: proceed [12:52] Right. I object to a package [12:52] It isn't one [12:52] And I've always disliked the pseduo-packages on the Debian BTS [12:53] StevenK: would you mind if we have our options clarified? [12:53] StevenK, OK. What do you suggest? [12:53] mok0: Nope. [12:53] persia: Further Discussion [12:53] I suggest that persia goes ahead but we discuss again later [12:54] StevenK, Before I discuss feasability and acceptance? What needs discussion? [12:54] * sebner agrees [12:55] We need some technical input from the LP guys. [12:55] Right, sorry, I am trying to do four things at once. [12:55] They may have their own thoughts on the matter [12:55] * NCommander has one final topic to bring up [12:55] persia: Okay, if your action is discussion, then I withdraw my objection [12:55] Wait, we need to summarize [12:55] StevenK, OK. Thanks. [12:56] I'll bring it back before preparing any package for REVU. [12:56] persia: if you are going to discuss with the LP guys, can you please ask if this could be done via a project? [12:57] mok0, I'll ask, but I asked about fixing that bug about two or three weeks ago, and was definitely told it wasn't a priority. [12:57] I think most agree that it would be good to remove ITP from the bug list, but let's not decide on the implementation [12:58] Perhaps we can decide the former? [12:58] ACK [12:59] I don't want to do that. [12:59] It's precisely contrary to the item I brought to the meeting. [12:59] I like using bugs for packaging requests. [13:00] persia, I think he means bugs against the Ubuntu project, not removing bugs period [13:00] persia: don't you mean: "I like using LP to track packaging requests"?? [13:00] Ubuntu isn't a project. [13:00] Oh. Yeah. I'm good for that. [13:00] mok0, No. I like using bugs. I *really* don't care if it's LP. [13:01] NCommander: yes that's what I meant [13:01] I think the issue merits more discussion [13:02] +1 [13:02] +1 [13:02] +1 [13:02] So [13:02] interesting idea but more discussion is appreciated [13:02] So I'm to talk to LP and such, or not? [13:02] we can always agree on that, lol [13:02] persia, its good to know that LP can/can't do :-) [13:03] persia: yes talk to LP, find out what options we have [13:03] There's a conveniently placed bigjools over there -> [13:03] NCommander: want/don't want? ^ ^ [13:03] persia, so ask the LP devs, but lets not make any changes until we know specifically need [13:03] Well, OK, but it's always easier to talk to LP when there's an actual use case behind any discussion. [13:04] persia: you can tell them if it's possible, we'll do it :P [13:04] persia: afaiu, they need to make changes to LP no matter what [13:05] mok0, Well, there are changes, but if we go with a non-psuedopackage, it doesn't require any LP code changes. [13:05] ok yes [13:06] the discussion section in the bug section of that package will be *huge* [13:06] iow unusable [13:06] Well, more usable than what we have now, but yes, far from ideal. [13:08] I far prefer a separate LP project, but I think I'm alone with that wish [13:08] mok0, nope [13:08] If we can turn distro tasks into project tasks and vice-versa, a project would work. [13:09] persia: will you ask about that? [13:10] mok0, I'll ask, but as I've said, I asked about that a couple weeks ago, and the response wasn't promising. [13:10] persia: tell'em we want it [13:10] mok0: You forget that we're only Ubuntu. [13:11] Right. I'm done. [13:11] wgrant: one of the really big LP users, though... [13:11] mok0: One would think so, yes... [13:11] mok0: the biggest by far? [13:12] NCommander: last item? [13:12] [topic]REVU Usage Permissions [13:12] New Topic: REVU Usage Permissions [13:12] Its fairly common knowledge we have an extremely high signal to noise ratio on REVU [13:13] we do? [13:13] * persia objects to this topic [13:13] Ok [13:13] * NCommander drops the topic [13:13] then what's with all the threads saying that things should be expired, if they're all great? [13:13] It's a topic of current ML discussions. Bringing it to the MOTU Meeting without prior notice doesn't satisfy the goals of discussion. [13:13] Fair enough [13:13] Ok, anyone else got anythign? [13:14] Adding it to the agenda for the next meeting would be good though :) [13:14] lol [13:14] any final news? [13:14] Well we can discuss it without make decision, yes? [13:14] Yes, that was the point [13:14] NCommander: You mean low signal to noise? [13:14] maybe [13:15] This is about ~6 packages about to be "expired". Those packagers probably don't care anymore [13:15] mok0: probably? very likely I'd say [13:16] OTOH, we can go over and comment on them right now... [13:16] It's REVUday!! [13:17] * persia tends to find reasons to reject packages before expiring them. s/hardy/jaunty is always a good start [13:17] Anyway. Is there anything else for this meeting, or shall we reconvene at 20:00 on the 28th? [13:18] +1 [13:19] * sebner agreees [13:19] NCommander ? [13:19] #endmeeting [13:19] Meeting finished at 07:19. === gondim_ is now known as Andre_Gondim === ogra_ is now known as ogra === Ursinha is now known as Jorjao === Jorjao is now known as Amelinha === Amelinha is now known as Ursinha === Ursinha is now known as Jorjao === Jorjao is now known as Amelinha === Amelinha is now known as PowerRanger