[01:42] @now rome [01:42] emgent: Current time in Europe/Rome: May 09 2008, 02:43:38 - Current meeting: Bugs for Hugs Day [01:50] @now [01:50] no0tic: Current time in Etc/UTC: May 09 2008, 00:51:14 - Current meeting: Bugs for Hugs Day [01:50] :D [03:26] @now rome [03:26] emgent: Current time in Europe/Rome: May 09 2008, 04:27:02 - Current meeting: Bugs for Hugs Day [03:26] @schedule rome [03:26] emgent: Schedule for Europe/Rome: Current meeting: Bugs for Hugs Day | 09 May 06:00: MOTU | 09 May 18:30: Ubuntu 8.04.1 Team | 14 May 08:00: Platform Team | 14 May 23:00: Server Team | 15 May 15:00: Desktop Team [04:24] @now [04:24] RoAkSoAx: Current time in Etc/UTC: May 09 2008, 03:25:41 - Current meeting: Bugs for Hugs Day [04:25] @schedule [04:25] RoAkSoAx: Schedule for Etc/UTC: Current meeting: Bugs for Hugs Day | 09 May 04:00: MOTU | 09 May 16:30: Ubuntu 8.04.1 Team | 14 May 06:00: Platform Team | 14 May 21:00: Server Team | 15 May 13:00: Desktop Team === RoAk is now known as RoAkSoAx [04:59] well [04:59] should we get on with it? [04:59] 2 mins by my clock here. [04:59] 1 min === ubottu changed the topic of #ubuntu-meeting to: Current meeting: MOTU | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 09 May 16:30 UTC: Ubuntu 8.04.1 Team | 14 May 06:00 UTC: Platform Team | 14 May 21:00 UTC: Server Team | 15 May 13:00 UTC: Desktop Team [04:59] ah, I have 2 after here [04:59] Any volunteers to chair? [04:59] * ajmitch is just here for the LaserJock fan club [05:00] do we have the fancy bot in here andymore? [05:00] not that I can see [05:00] I can chair but I don't know how to use the bot [05:00] Damn bots, we become too dependant on them. [05:00] That's OK. There's no bot. Are you sure you want to both chair and have all the agenda items? [05:00] they'll take over one day [05:01] persia_: then you chair :-) [05:01] Bah. [05:01] I can chair if you'd like. [05:01] Welcome to the MOTU Meeting for 9th May 2008. [05:01] how about we hold a meeting on how to hold the MOTU meeting? [05:01] * TheMuso gets the agenda up. [05:01] The agenda is available from https://wiki.ubuntu.com/MOTU/Meetings [05:02] Who would be willing to handle minutes & announcements for the next meeting? [05:02] * TheMuso raises his hand. [05:02] TheMuso: Thank you. [05:02] OK. First up, LaserJock re: Name/need for MOTU fan club? [05:02] yeah [05:02] so this is from our last meeting [05:02] state your rationale behind this suggestion [05:03] where we renamed ubuntu-universe-contributors to revu-uploaders [05:03] some people thought we should have an open team for people who wish to associate with MOTU can join [05:04] So people can LP badge hunt? [05:04] so that they can feel involved? [05:04] this team would have no functional purpose then? [05:04] it's purpose is to help people find "identity" [05:04] ajmitch: not presently no [05:04] Badge hunting / feeling involved sounds clearer than "fan club" to me. [05:04] Very much so. [05:04] so this would come before the team that grants ubuntu membership which is prior to upload rights? [05:04] persia_: yeah, I just threw it up there [05:04] badge hunting is a time honoured wow tradition [05:05] ajmitch: yep [05:05] team proliferation [05:06] Yeah. I don't really see how membership of an entirely open team maps to feeling involved in anything but a transient way. [05:06] sebner last time said he joined u-u-c just to gain some identity with the team [05:07] RAOF: like my involvement with MOTU? ;) [05:07] I've seen a few times where people have asked if they could join a team to get into MOTU [05:07] I'd suggest hanging around in #u-motu is both a better way to feel involved and learn useful things at the same time. [05:08] RAOF: for sure, but that doesn't really say anything about a team [05:08] it's an orthogonal issue [05:08] Doesn't make sense to me. [05:08] persia_: thoughts? [05:08] LaserJock: I thought the idea was to make people feel more involved? [05:09] anyone can create such a team, to be honest [05:09] RAOF: for people who see joining such a team, yes [05:09] * persia_ temporarily takes off the "chair" hat. [05:09] but it doesn't mean that joining #ubuntu-motu is any less important [05:09] that must be a heavy hat [05:09] ajmitch: it's a small chair [05:09] Such a team might make sense, if there was a known purpose, and a clear demand. I'm not sure there is value if there is no demand, and no known purposed [05:10] agreed for sure [05:10] And that it's a distraction from a useful way to feel involved; ie: hang in #motu or join the motu list. [05:10] my agenda item is mostly a response to what sebner said last time [05:11] it would give people some way to say "I'm a foo! [05:11] " [05:11] but no more [05:11] well [05:11] fill in foo with the appropiate team member name [05:11] we currently have no good way of seeing who's associated with MOTU [05:11] in terms of new people [05:12] what does it mean to be associated? [05:12] are you looking at potential MOTUs? [05:12] revu-uploaders? [05:12] well, it shows interest [05:12] and potential for contribution [05:13] we'd surely get badge hunters [05:13] What would we do with the knowledge of interest or potenital contribution? [05:14] I'm not opposed to the idea, I just don't see it being much use [05:14] maybe as a psychological stepping-stone into MOTU [05:14] i think people show more interest when they join a channel or a mailling list than just a lp team [05:14] I mean, that we wouldn't get by people popping up in #motu or on the motu list? [05:15] well, would it be worth an email to -motu asking if people are interested? [05:15] * persia_ redons hat [05:15] There doesn't seem to be much of either agreement or argument. [05:15] Maybe its something for the ML. [05:15] LaserJock: Could you put together a draft wiki page decsribing the potential team for representation at a future meeting? [05:16] (or the mailing list :) ) [05:16] persia_: probably because it's such a non-intrusive change that it wouldn't mean much to us either way [05:16] persia_: I think an email would be best. I'm not sure a wiki page is going to do much right now [05:16] ajmitch: Perhaps, but my immediate concern is about finishing the agenda within an hour :) [05:16] well the next 2 items aren't too long, I'm sure :) [05:16] persia_: if we get lost of response I/we can do a wiki page for a formal proposal [05:17] LaserJock: Makes sense. Anything else you want to add for this item, or shall we go to the next? [05:17] nah, I just wondered what people thought of the idea [05:17] I think we all pretty much agree [05:17] next item is fairly simple, I think [05:17] persia_: moving on? [05:17] OK. Next item: LaserJock re: Require 7 day aging period in -proposed for SRUs? [05:18] ok [05:18] * persia_ doesn't always type sufficiently quickly [05:18] so our current SRU wiki page only says that verification requires 2 + votes and no - votes [05:18] If, as I've been told, archive admins require this anyway, then there's no reason not to sync MOTU SRU policy with what's expected by archive admins [05:18] however, the ArchiveAdmin page says that there is a 7-day aging period [05:19] * ajmitch lets LaserJock 'talk' :) [05:19] as a MOTU SRU member I think we should resolve the two for sure [05:19] and don't mind 7-day aging [05:19] ok, I agree, objections to the plan? :) [05:20] *however* I do see where we need to be able to have exceptions to that [05:20] IMO we sync with what main has. [05:20] Less confusing. [05:20] TheMuso: well, Main doesn't have it either [05:20] LaserJock: So you're saying we should have a 7 day aging period? [05:20] this is w.u.c/StableReleaseUpdates vs w.u.c/ArchiveAdministration [05:21] SRU has no 7 day aging, ArchiveAdmin does have it [05:21] Right. [05:21] From my reading of https://wiki.ubuntu.com/MOTU/Meetings/2007-11-23, ~motu-sru may adjust the plan as required, at their will, so long as MOTU is notified of the changes. [05:21] and pitti says 7-days is his current SOP [05:22] (sorry if its kinda late) I would like to make a suggestion. If you create a team, so called a fan club, you should give that team special tasks so that they will feel more involved than just being part of a ML or being active on a #u-motu. That way, those team members will have some specifical things to work on and not just going around searching for things to do... For example, all those team members would work in certain type of bugs, maybe [05:22] only work on merges or things like that. [05:24] so [05:24] everybody think going with the 7-day aging is cool? [05:24] Yep. [05:25] Yes, if that's archive admin or main sru policy. [05:25] Just to ensure consensus, I'd like there to be an ACK from one of jdong, imbrandon, or dktrkranz, although not necessarily in this meeting. [05:26] (unless you decide it's just an oversight by the last person to edit the page) [05:26] sure, I can email them [05:26] OK. Anyone disagree with a 7-day aging period, or shall we move on? [05:26] well, I think perhaps the ArchiveAdmin page was just never updated [05:27] Move on IMO. [05:27] but I think it's reasonable and if that's the way they've been operating anyway [05:27] might as well get it written down for everybody [05:27] Next up: LaserJock with General thoughts on microrelease exceptions to "minimal diff" requirement for SRUs [05:28] ok, so the TB approved a process for having exceptions to the "minimal changes to fix the bug" rule for SRUs [05:28] Is there a link to the exception process? [05:29] https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions [05:29] basically, the TB approves packages that do stable branch microreleases [05:30] right now there is only firefox, thunderbird, and postgresql [05:30] I emaild the TB about the possibility of MOTU SRU doing the approval for Universe packages [05:31] which packages in universe do you think this may apply to? [05:31] well, often times gnome-related packages have a stable branching scheme [05:31] one I know personally is gchemutils [05:32] but perhaps glom, as we've been discussing with Murray Cummings about what to do there [05:32] And a test suite? Do we want to maintain that criterion? [05:32] so this suggestions is mainlly that the motu-sru team should petition the TB to be allowed to decide? [05:32] ajmitch: well, the TB told me to liase with slangasek on the issue, which I'm working on [05:33] basically, given good enough testing it shouldn't be a big deal to do new uptream microreleases [05:33] ok, so what are you asking from us? [05:34] well, basically is this something you guys would like to see? [05:34] sure, if the packages involved are sane [05:34] I'm looking at things that might streamline the SRU process [05:35] I don't touch many packages with a test suite, let alone one that's run during package build. Are there many such packages in universe? [05:35] * ajmitch is not involved in the SRU process, so doesn't have much of opinion worth considering [05:35] (speaking only as myself): In addition to approved microrelease exceptions per-package, it may be interesting to look at selected microreleases by non-exempt packages where only a subset of the closed bugs would otherwise be considered suitable for SRU. [05:35] RAOF: I'm guessing a test suite would not be required. [05:35] Right. That'd be worth mentioning :) [05:36] RAOF: well, I haven't specifically thought of that [05:36] but the number of packages with test suites is pretty small [05:36] and Universe, in general, just isn't so strict [05:37] Yeah. [05:37] Yeah I'd like this. [05:37] persia_: right [05:37] 5~/c [05:37] one thing I'm seeing in SRU is that we fix one bug at a time [05:38] if an upstream does a bug-fix-only release that fixes 5 bugs, one of them being an SRU bug, I think we're making things better [05:38] I agree. [05:38] Absolutely. [05:38] I'm also looking at upstream testing [05:39] upstreams often are going to have more testing than we're going to be able to do in -proposed [05:39] so I sometimes worry about the potential for us to cause a regression/bug in cherry picking [05:39] trying to cut down on the number of "you all suck" blog posts after a release? [05:39] yes, that too :-) [05:40] we want to balance keeping user's systems stable with the need to get usptream fixes to users [05:41] in an ideal world they'd be the same thing [05:41] in any case [05:41] I just wanted to hear people's feelings on "opening" up a little more to upstream bug-fix-only releases [05:42] well, that and I thought we should have an agenda for tonight ;-) [05:43] * ajmitch is happy enough with the idea [05:43] * ajmitch is also not involved in approving such packages :) [05:44] on a somewhat side note, I think MOTU SRU is really kicking butt right now [05:44] Agreed. [05:44] Anyone else want to express an opinion about opening this right now? [05:45] Nope. I'm broadly in agreement. [05:45] OK. LaserJock: Please continue keeping us all informed about SRU stuff. [05:45] Does anyone have any other business they would like discussed at today's MOTU Meeting? [05:45] yeah, I just don't want to ramrod things through without getting people's thoughts [05:45] * ajmitch can't wait to join the laserjock-fan-club team on LP [05:46] pfft [05:47] persia_: I think I'm good [05:48] Actually, I've one. The next meeting is scheduled for 23rd May, 12:00 UTC, which is during UDS. Anyone else think the 30th might be a better date? [05:48] Yes. [05:48] Things will be in full swing at that time. [05:48] i.e during uds. [05:49] Anyone really want to have the meeting on the 23rd? (you have seconds to speak, or you wait a week for the meeting) [05:49] (err.. 120 seconds) [05:49] yeah, I think moving it to the 30th is reasonable [05:49] I don't know how many people are going to UDS but it I don't think we exactly have any pressing issues [05:50] The 30th seems reasonable. [05:50] There will be a lot of MOTU folk there. [05:50] great [05:50] so that's a good reason to postpone [05:51] OK. Next meeting will be 12:00 UTC on the 30th then. [05:51] Meeting adjourned. [05:51] Thanks fols. [05:51] folks [05:52] awesome [05:52] thanks everybody === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Bugs for Hugs Day | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 09 May 16:30 UTC: Ubuntu 8.04.1 Team | 14 May 06:00 UTC: Platform Team | 14 May 21:00 UTC: Server Team | 15 May 13:00 UTC: Desktop Team | 21 May 06:00 UTC: Platform Team === asac_ is now known as asac === Tweenaks is now known as Treenaks === gnomefre1k is now known as gnomefreak === Martinp24 is now known as Martinp23 === jw2328_ is now known as james_w === ubottu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 09 May 16:30 UTC: Ubuntu 8.04.1 Team | 14 May 06:00 UTC: Platform Team | 14 May 21:00 UTC: Server Team | 15 May 13:00 UTC: Desktop Team | 21 May 06:00 UTC: Platform Team | 21 May 17:00 UTC: LoCo Council === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Ubuntu 8.04.1 Team | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 14 May 06:00 UTC: Platform Team | 14 May 21:00 UTC: Server Team | 15 May 13:00 UTC: Desktop Team | 21 May 06:00 UTC: Platform Team | 21 May 17:00 UTC: LoCo Council === gnomefre2k is now known as gnomefreak [17:21] ******* Pedro Villavicencio Garrido -----------> ¿¿¿porque me expulsaste del canal #ubuntu-cl ???? ¿¿¿que te pasa???' [17:21] ******* Pedro Villavicencio Garrido -----------> ¿¿¿porque me expulsaste del canal #ubuntu-cl ???? ¿¿¿que te pasa???' [17:22] ... [17:22] mruiz: you here for ubuntero-ar? [17:23] ubuntero-ar: you're insulting us, that's why [17:23] ubuntero-ar: el lugar mejor para descutir esto seria en #ubuntu-irc [17:23] jdavies , hi. Yes... days ago we had some troubles with him [17:23] hi pedro_ [17:23] this is really not the place... [17:23] estaba buscando al sujeto y esta acá basta de defensa coorporativa [17:23] best take this to #ubuntu-irc [17:23] jdavies: agreed :-) [17:24] ubuntero-ar: por favor haz: /join #ubuntu-irc [17:25] /join #ubuntu-irc [17:25] sin el espacio [17:28] afternoon [17:29] * pitti does the Hardy dance [17:29] @now [17:29] pochu: Current time in Etc/UTC: May 09 2008, 16:30:29 - Current meeting: Ubuntu 8.04.1 Team [17:29] * asac jumps in [17:29] morning, folks [17:30] * ogasawara waves [17:30] * mvo waves [17:30] * zul waves [17:30] * bdmurray waves [17:30] http://people.ubuntu.com/~ubuntu-archive/pending-sru.html is rocking hard [17:31] pitti: does tagging bugs as hw-specific still get reflected there? [17:31] don't know about you guys, but for me it helped tremendously to actually *use* hardy while doing fixes for it :) [17:31] pitti: those are the ones we should verify, right? [17:31] bdmurray: yes [17:31] bdmurray: (hw) [17:31] asac: right, the non-green ones [17:32] I spend about 2 hours on SRU processing every day, so people are very active :) [17:32] :) [17:32] bookmarked [17:32] * seb128 hugs pitti for the good work [17:32] * pedro_ waves [17:32] hello pedro_ [17:33] hey seb128 [17:33] ok, let's go ahead and get started, I'll direct evand to the logs afterwards [17:33] So if I am running the proposed kernel and have no issues with it how do I document that? [17:33] I just have two points, but let's hand the mike to slangasek [17:33] (though perhaps we're already started :) [17:33] likewise, I just have a couple of things [17:33] bdmurray: for cases like that I usually say exactly that in the bug [17:33] pitti: but there are 9 bugs for the kernel... [17:33] first, please keep in mind that any bug that's going to be fixed in an SRU needs to be tracked in both hardy and intrepid, which means nominating the bug for release [17:34] ^ also my point [17:34] please create *both* hardy and intrepid tasks [17:34] We currently have a large number of bugs that are milestoned but have not yet been targeted for the release! [17:34] so that we won't forget to fix stuff in intrepid which we SRUed [17:34] (You can see the difference in https://bugs.launchpad.net/ubuntu/hardy/+bugs?field.milestone%3Alist=1264, and https://bugs.launchpad.net/ubuntu/+bugs?field.milestone%3Alist=1264) [17:34] (many bugs don't even have hardy tasks) [17:34] slangasek: so the right search to get a list of bugs that need are properly targetted would be to search in "hardy" + 8.04.1 tag? [17:35] Sorry about that. [17:35] asac: correct; the first of those links I provided is the list of bugs that are tracked as "release-critical" for .1. [17:35] i was a bit confused what search i should exactly use to get the right ones :/ [17:36] evand: hi; will send logs in /msg [17:36] thanks slangasek [17:37] of course, in practice since there are so *many* more bugs that are targeted for .1 without being targeted to the release, I can't ignore the other set either - but if any of those bugs are *yours*, please make sure you talk to me about getting them targeted to release. :) [17:37] slangasek: so whould someone go through the second link and nominate those that look properly milestoned? [17:37] asac: yes, that's an ongoing task of mine, but I would like us to get to the point where I don't have to poll the page :) [17:37] asac: you can do that 'on the go' when you start working on a bug [17:38] pitti: right. question is if we should work on all bugs of the second link [17:38] maybe slangasek wants to filter them first [17:38] slangasek: +milestone/8.04.1 should be good enough for an overview, no? [17:38] https://edge.launchpad.net/ubuntu/+milestone/ubuntu-8.04.1 that is [17:38] that's my preferred page [17:39] since it shows assignments and doesn't care (so much) about tasks [17:39] asac: for the moment, I'm just asking that people make sure that any bugs that their team has identified as targets for 8.04.1 get targeted to the release [17:39] asac: I'll take care of filtering the rest and confirming/denying release nominations [17:40] for the record, yesterday the desktop team went through the list and assigned desktopish stuff to people [17:40] it would be good if the other teams could do the same [17:40] slangasek: ok, so we should only work on nominated ones and the teams should get around and fix that list as good as possible [17:40] IMHO it is very important to have assignees [17:40] will do that for mozilla stuff now [17:40] unassigned milestoned bugs -> will be forgotten about [17:40] pitti: right, unfortunately I don't find a way to filter that list to bugs that are properly nominated :) [17:40] asac: you should be able to create the actual tasks, not just nominations [17:40] pitti: yes. word confusion here [17:41] pitti: so I need to catch up on that first [17:41] slangasek: you mean sth. like https://bugs.edge.launchpad.net/ubuntu/hardy/+nominations?field.subscriber=ubuntu-sru ? [17:41] well, probably not with subscriber, but rather with a milestone [17:42] pitti: roughly, yes [17:42] but then, that's the page I already linked to :) [17:42] ok, the next thing from me is to check in and make sure that everyone's workloads are appropriate, or whether we need to try to redistribute [17:42] https://bugs.edge.launchpad.net/ubuntu/hardy/+nominations?field.milestone%3Alist=1264 [17:43] slangasek: ^ I think that's pretty good [17:44] yes. It's not the same view, though, it lacks the assignee info you were keen on :) [17:45] slangasek: right, but ideally this list would be empty, so we can just go through and accept/deny [17:45] * slangasek nods [17:45] so, no comments from anyone on workload? [17:45] no Im good [17:45] * pitti is fine, he'll grab some more bugs (and generate some with the /etc upgrade diff) [17:45] help on desktop bugs is welcome [17:45] I'll never manage to tackle everything singled handed [17:46] anyone with particular expertise on openssl? I could use a second set of eyes on a memory leak.... [17:46] i see pitti's name in the changelog :-) [17:46] *cough* [17:46] kirkland: happy to review [17:46] slangasek: i am still utilized with catching up on my own SRU stuff. i expect to have cycles for others by mid of next week, so could start to assign some low-hanging fruits to me. [17:46] that's what i thought :-) [17:46] seb128: is there a good list somewhere of the desktop bugs in question? [17:46] pitti: i'll ping you later [17:46] own == mozilla related [17:46] kirkland: (although I'm not an openssl guru at all, but I can give it a general review) [17:46] I can probably handle taking on a few more bugs in the near future, but I'd like to make sure I get through the major installer issues first. [17:46] asac: great, thanks [17:46] slangasek: bugs in those lists assigned to ubuntu-desktop [17:47] the server team keeps track of server related bugs on the wiki for what its worth works for us [17:47] but remember that i am 50% ;) [17:47] By all means, assign things to me as well [17:47] evand: oh, btw, I did a one-off hardy livecd build yesterday; if it checks out I can go ahead and cron something [17:47] hooray [17:47] that will make my life much easier, thanks [17:47] oh, yeah, that's one of my current TODOs, cron hardy-proposed dailies [17:47] we need them to SRU-verify installer things [17:48] kirkland: I also have some familiarity with OpenSSL , so if I'm easier to grab than pitti on account of timezones or whatnot, feel free [17:48] slangasek: thx. [17:49] encryptz: maybe just grab some from the unassigned list you feel comfortable with? [17:49] seb128: hmm, currently I find zero bugs in those lists assigned to ubuntu-desktop, maybe I'm doing something wrong [17:50] erm, evand, I meant [17:50] maybe we can setup a wiki page with a list links to tasks? [17:50] https://edge.launchpad.net/ubuntu/+milestone/ubuntu-8.04.1 has plenty [17:50] slangasek: ^ [17:50] then I guess my query is broken somewhere :) [17:50] argh, please no wiki page for tracking bugs [17:50] oh, these are assigned to desktop-bugs, not ubuntu-desktop :) [17:50] pitti: ok, I'll give a look through it [17:50] slangasek: https://bugs.edge.launchpad.net/~desktop-bugs/?field.searchtext=&orderby=-importance&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.milestone%3Alist=1264&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.tag=&field.tags_combinator=ANY&search=Search [17:51] evand: (sort first by status, then by assignee, otherwise you'll go crazy) [17:51] haha ok [17:51] shorter URL: https://bugs.launchpad.net/ubuntu/+bugs?field.milestone%3Alist=1264&field.assignee=desktop-bugs :) [17:51] seb128: I'll grab bug 210379 [17:51] ok, ^^ there's the list of bugs that seb128 is asking for help with on desktop [17:51] pitti: well ... there are lots of links floating around :) i don't want the bugs on wiki page ... just the links we paste here ;) [17:51] Launchpad bug 210379 in glib2.0 "should not list mounts that the user doesn't have permission to use" [Low,Fix committed] https://launchpad.net/bugs/210379 [17:51] that's my competency [17:51] asac: ah, yes, that would be good [17:51] pitti: that one should already be fixed [17:52] seb128: no, see my latest bug comment (upstream and LP) [17:52] pitti: though the fix doesn't work for you? I'm just reading my mails about that [17:52] ok, thanks [17:52] assigned to me [17:52] (it takes some communication with hal probably) [17:53] pitti: right, I suggested that on the bug before too (checking for local mounts) [17:53] seb128: I saw [17:53] zul: I didn't get a chance to chase up all of those bugs before the meeting, but yes, we ought to have all of the relevant bug state in LP itself instead of stored externally in a wiki; pitti and bdmurray are both very good at generating static web pages from LP queries, so I'm sure one of them could show you guys how to get the reporting view you want without trying to keep a separate authoritative source for the data [17:54] slangasek: sure but Rick asked me to do that so he could track them better [17:54] zul: e. g. http://people.ubuntu.com/~ubuntu-archive/pending-sru.html is dynamically generated for tracking bugs, and IMHO it's very useful (and updated hourly) [17:54] zul: noted, I'll talk to Rick then :) [17:54] but I will ask pitti and bdmurray as well [17:55] zul: I'm happy to add more stuff to it if you need something [17:55] pitti: thanks [17:55] zul: or categorize it differently, etc [17:55] it's reasonable to want a page that lets the team get an easy overview, but this page needs to be built from LP data [17:56] 5 minutes on the clock, any other business? [17:56] o/ [17:56] nope [17:56] I would appreciate if you guys could follow some rules which would really help me with the SRU bug management: [17:56] pitti: go ahead :) [17:56] * make sure that the bug has proper and correct tasks [17:56] * try to avoid stacking uploads into -proposed without getting the older ones into -updates first [17:56] * if you do upload a new version into -proposed, use -v [17:57] (otherwise they become a nightmare to track) [17:57] * after you uploaded to -proposed, don't forget about it; encourage and chase people to get it tested! [17:57] * mvo coughs for being guitly of point (2) [17:57] with the current number of SRUs, I can't possibly chase all bugs to get verified [17:58] I'm a bottleneck for SRU processing, so I'd like to spend less time with fixing tasks, asking people whether stuff is fixed in intrepid, asking for test cases, etc. [17:58] on that note, bdmurray had also asked me about folks not providing test cases for their SRU uploads [17:58] I do see that this is hard for things like the current kernel upload [17:59] I guess for those we can just all use the new kernel for two weeks and then take the plunge [17:59] this is documented on https://wiki.ubuntu.com/StableReleaseUpdates as one of the responsibilities of the SRUer - please provide a clear test case in the bug description wherever possible, so that our SRU verification team can get a handle on these bugs with a minimum of effort [17:59] also, it's perfectly reasonable to ask bug reporters for testing stuff [17:59] even more so for hardware specific issues [18:00] anybody has an issue with the evolution switch to gnome-keyring btw? [18:00] * pitti doesn't use a keyring in evo, didn't test [18:00] but I can set it up if required [18:00] pitti: this is in reference to email passwords, AFAIK? [18:00] I don't feel strongly about it, I think it's better to have the keyring used for the lts but we can do without it too [18:00] I don't use evo for email, is the thing- [18:00] pitti: what about test cases that require special hardware? [18:00] well, I only have a local Maildir, [18:01] zul: as I said, I think for those the bug reporters should test it [18:01] pitti: no ldap directory configured in evo either? [18:01] pitti: gotcha [18:01] seb128: not ATM [18:01] seb128: I did have LDAP for taks and contacts at one point, but that was only for testing [18:01] zul: It'd be helpful if those were tagged as hw-specific too [18:01] ok [18:01] (about three years ago perhaps) [18:02] bdmurray: sure [18:02] seb128: let's discuss that offline [18:02] and we're at time - any last-minute comments before everyone runs away? :) [18:02] pitti: ok [18:03] adjourned. thanks, folks! [18:03] thanks [18:03] thanks everyone [18:03] oh [18:03] next meeting? [18:03] 'when we need one'? [18:03] I'll send out a proposed meeting time for next week by email [18:04] thanks [18:08] thanks [18:09]