=== _neversfelde is now known as neversfelde === asac_ is now known as asac [12:01] Hi [12:01] Hi. [12:02] Anyone else here for the MOTU Meeting? [12:02] Afternoon. [12:03] * Hobbsee waves [12:04] RIght. Let's wait until we're 5, and get started. [12:04] Apparently there's something going on in classroom [12:04] (more would be better, but less is boring) [12:04] Yes, the "How to run a Bug Jam" session. [12:04] * james_w waves [12:05] OK. Who wants to chair? [12:05] * james_w is writing a spec, but will pay attention [12:05] * mok01 nominates persia as chair [12:05] OK. [12:05] #startmeeting [12:05] Meeting started at 06:05. The chair is persia. [12:05] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [12:05] [link] https://wiki.ubuntu.com/MOTU/Meetings [12:05] LINK received: https://wiki.ubuntu.com/MOTU/Meetings [12:06] [topic] Discussion about REVU [12:06] New Topic: Discussion about REVU [12:06] mok01, You're up. [12:06] Well, I've written up a proposal for a revised workflow [12:06] https://wiki.ubuntu.com/REVUWorkflowProposal [12:06] [LINK] https://wiki.ubuntu.com/REVUWorkflowProposal [12:06] LINK received: https://wiki.ubuntu.com/REVUWorkflowProposal [12:07] In principle it's not very different from what we have today [12:07] It's just organized so the flow is clearer to both uploaders and reviewer [12:08] and it gives us the possibility of closing for new packages [12:08] so we can focus on the ones that are already in the queue [12:08] I don't really understand the value of closing for new packages at certain times. In terms of a typical cycle, when would you expect it to be closed? [12:08] mok01: I personally am against the idea of closing REVU for new packages [12:08] persia: He had suggested after Feature Freeze iirc [12:09] That is one option, but I propose that it is up to the MOTUs to decide [12:09] To me that's counterintuitive. I'd think we'd want new uploads (for the next release) between FF and release, and just focus on things in the queue from open to FF when we can actually upload. [12:09] In practice, of course, REVU is mostly completely ignored after FF, so perhaps it doesn't matter. [12:10] Yes, the problem is that the influx of new packages is greater than our capacity to process them [12:10] Even if we have way more packages than we can handle, I think having them available on REVU is much more beneficial than not having them at all [12:10] mok01: The same thing could be said about bugs on Launchpad. Should we stop accepting new bug reports? [12:10] nhandler: don't be silly [12:10] nhandler: well, apport does get turned off for crashes in stable releases, for that very reason, fwiw. [12:11] Anyway, closing is a minor point. [12:11] As for restructuring the lists, I am still a little unclear as to what this is meant to accomplish [12:12] According to the proposal, unreviewed uploads will be on it's own list [12:12] The packages that have received >= 1 review, move to the "In process" list [12:13] and then the progress pretty much like now [12:13] But what is the benefit of having that? Having more lists just means that a MOTU has to make a concsious decision about what list to review [12:13] Currently, packages with 1 advocation are at the top and easy to see [12:13] Packages that need work are at the bottom and out of the way [12:13] nhandler: ATM, the list is cluttered with completely new uploads and people putting the final touches on their package [12:14] mok01: This is one reason more MOTUs should subscribe to packages [12:14] And cluttered by packages that already have an advocate, but the 2nd one has asked for some changes [12:15] nhandler: that's voluntary, of course [12:16] mok01: It is, but subscribing to packages that you review would solve a LOT of the problems we currently have [12:16] Question: are we actually pushing people not to start doing MOTU stuff by doing new packages? I've seen some of the IRC channel people pointing in the direction of patches and such, but haven't seen a memo on the official status [12:16] nhandler: I have reviewed a LOT this cycle, you don't need to explain to me how it works [12:17] mok01: These comments are dirrected at you personally, they are just general comments [12:17] Hobbsee: That is my understanding. But I don't think there is any official policy about it yet [12:17] nhandler: well, you prefixed your comments with my nick [12:17] nhandler: because, if that's the case, this will not be such an issue next cycle. [12:17] There's never been a policy about either way. [12:18] which means one could probably advertise for a concerted effort once, and people not getting hit with consistent mails about it being REVU day yet again [12:18] Hobbsee: I think that's an issue we might discuss separately. I'd like to see some kind of selection of the new packages, but let's wait with that discussion [12:18] The set of people who edited the GettingStarted page chose to focus on Packaging. The set of people who edited the Contributing page chose to focus on patching, more people point at GettingStarted. [12:18] The way to address this is to edit the wiki, not wait for some decision. [12:19] I have drafted a proposal for a getting started page that points people towards bug fixing etc [12:19] * DktrKranz waves [12:19] * nhandler has to leave [12:19] mok01: Hurrah! I agree that it should be discussed separately, but this discussion has that as a dependancy. [12:20] Hobbsee: well, not really. We can modify the workflow without such a decision [12:20] score :) [12:20] IMO it will make reviewing life easier, and we can collectively focus on packages where the uploader is active [12:21] Right now, there are > 125 packages in the "needs-review" section, so by stochastics, our effort is spread on all of them at once [12:22] Of those 125, I estimate that about half have never receieved a review [12:22] So it would be good if they did not appear in the same list [12:22] Because then everybody would focus on the 60 or so, and they would get processed quicker [12:23] To more satisfaction for all [12:23] Well, what's the goal? [12:23] I always thought the goal was to get in the most interesting packages that were missing. [12:23] Focusing on "active uploaders" doesn't seem to help this goal. [12:23] The goal is to get a process where we don't spread ourselves too thin on a very large number of uploads [12:24] I'd rather MOTU focused on packages that were interesting to them, or first-uploaded in the case where they just were doing some REVU. [12:24] persia: my proposal does not rule that out [12:25] persia: see use case 4 [12:26] Hrm. I see. [12:26] So it's not actually about retargeting workflow, but rather to give reviewers a better idea of what to expect when selecting a review? [12:26] Maybe we could just list the category in the table, rather than having separate lists? [12:27] That's a matter of layout I guess. [12:27] I don't see the point of having a very long cluttered list though [12:28] Well, if you're not specifying which should be examined, what part is the clutter? [12:28] Having different "kinds" of packages is good if a MOTU is looking at a given kind of package (i.e. I haven't much time, let's pick an almost good one)... [12:28] DktrKranz: exactly [12:28] ... but are we sure we don't focus too much on "almost ready" packages, discarding "New" packages? [12:29] that's my major issue with it [12:29] I don't think the ones that have previously been advocated should be considered those that don't need much review. [12:29] There is not much point of having 125 packages waiting for processing [12:29] I think those require the *most* detailed review, in case the previous reviewer missed something. [12:30] It's better to give the final review to a package to get it moving along the pipeline [12:30] It depends on how much detailed first review was [12:30] I try to have a deep review first [12:30] just to make sure major issues come out soon [12:30] persia: that's why I have the "Advocate" section, with packages that have 1 advocate. [12:31] They stay in that section [12:31] and don't go back to Processing unless the advocate removes the vote [12:31] it's frustrating to send back a package for a typo and then send back it again for a bigger issue. I think it discourages contributors. [12:31] DktrKranz: yes [12:32] mok01, Would perhaps continuance of advocacy meet that need: so that if someone advocates, the advocacy persists for further uploads? [12:32] persia: yes [12:32] My fear there is that a change might mean that I no longer wanted to grant advocacy. [12:33] persia: from the logic, that if you've advocated a package at a certain stage, it's ok to improve it [12:33] persia: then you could remomve your advocacy [12:33] One of the reasons I *don't* think it's a good idea to have new people packaging is because the changes that sometimes come in the final version are significant enough that I remove advocacy. [12:33] Yes, but that requires me to pay specific attention. When I have time for REVU, I tend to do *lots* of packages, and I don't tend to look at the same one twice. [12:33] persia: you still have that option [12:34] persia: you can leave a not to the next reviewer that you want to approve the final pacakge [12:34] What about have the second reviewer to ask for a confirmation of the first ACK before uploading? [12:34] :-) [12:34] * mok01 propose that we take a look at the REVU list now [12:34] http://revu.ubuntuwire.com/ [12:34] LINK received: http://revu.ubuntuwire.com/ [12:35] mok01, But then I still get poked, which I don't prefer :( [12:35] Then you have to trust your fellow MOTUs [12:36] Most of the packages at the top have never received a review. [12:36] They were uploaded in november [12:37] I have notes that tell me which packages I follow [12:37] so I go to the bottom of the list to see if any of those have come back [12:38] That is deceitful to the people at the top, who think they are next in line [12:38] I personally trust other MOTUs, I think we hadn't major issues with NEW packages so far, theygo through a-a review at a second stage and can eventually be modified once in the archives. [12:39] I'm not sure it's deceitful. Perhaps we just need to make it more clear that REVU is not a FIFO queue. [12:40] and probably will never be [12:40] A lot of people just give up and go away with a bad impression of MOTU [12:40] Look at the length of the needs-work list [12:41] mok01: I think mentors.debian.net have the same issues, packages are not processed regularly, but on a "i-have-time-to-do-some" basis [12:41] Well part of that is because it's not being trimmed. I used to archive stuff with 3 months with no upload or comment. [12:41] mentors,debian.net = never processed unless you find a sponsor [12:41] Anyway, part of the issue is the assumption that just uploading to REVU is a good way to learn. [12:41] people could be discouraged about long time for a review, but there are several options to speed up things [12:41] Many of the packagers with whom I communicate don't use the software in question, don't understand if it works, and are just learning packaging. [12:41] such asking in #ubuntu-motu during REVU days [12:42] That was less true in the past, but it certainly discourages me from REVUing things where I don't see the benefit. [12:42] DktrKranz: yes, I give priority to people in IRC [12:42] persia: you don't have to [12:42] Personally, I'd rather keep REVU *hard*, because I think we don't do enough for the packages we already maintain. [12:42] persia: good point. There are packages which are there just to say "hey, I've packed something!" [12:43] And discourage people from putting things there unless they really have some need to get it in the distro. [12:43] Now, though, we have PPAs and that ought to be able to take the load off REVU [12:43] Well, yes, but it's also taken some of the reviewers away. [12:43] persia: but that is part of another discussion [12:44] Since the introduction of PPAs, a number of reviewers have been reviewing PPA packages, rather than REVU,and I've seen more duplication of work, and less coordination of responses. [12:44] I don't remember what, but I noticed a package made with ch*ckinst@ll some times ago... [12:44] Although I have thoughts about how to choose packages for review, the proposal is ONLY about organizing the web page differently [12:45] I guess I just don't see the benefit. [12:45] persia: it wont be any worse for you then [12:45] Fair. [12:46] OK, so if we look at the top of the REVU page... the packages with the green icons [12:46] I'm in favour of it, no-review packages would be more visible than recently-touched packages, so we can focus REVU days to spot "New" packages [12:47] they have one advocate. I the next one wants a trivial change, it goes waaaayy down to the bottom of the Needs Review [12:47] now, we just can't [12:47] What about making that a toggleable option? So that if a MOTU requests a trivial change, they can check a box that would prevent the package from going down to the bottom of the list again? [12:48] nhandler: this would be handled better via "neutral vote", IMHO [12:49] "I don't like this, but it's minor and I won't push you back just for a typo" [12:50] It seems there's still an assumption of a FIFO queue. Do we want that for some reason? [12:50] I think it's better if the package remains in the Advocate queue when it has 1 advocate. It makes a big difference for the motivation of the uploader. [12:50] Sometimes the 2nd advocate asks for a package to be split. [12:50] but even so, the package is in pretty good shape [12:51] with copyright etc. [12:51] mok01: about REVU code change, do changes you propose affect current view of REVU page? Can both variant co-exist? [12:52] both variant = actual display of packages and new way [12:52] DktrKranz: uhm... well the web page is just a view of the data base, so I'd think so [12:52] so, we can have two pages [12:52] just to see if people like the idea [12:53] DktrKranz: Solomonic solution [12:53] so, it's just a matter of bring things back to repair [12:53] Didn't someone have a "testing" version of REVU when they were testing the new theme? [12:53] I'd like that. While I'm not seeing a benefit in the abstract, I might see one with the example. [12:53] Doesn't even need to be done in REVU code or live, but just a layout sample. [12:54] nhandler, There's a few of them that were set up. Dunno of any that are publically available. [12:54] if we can have a REVU server up for a while, we can test things and eventually push on main site [12:54] I could ask a friend of mine to host the stuff [12:54] I am willing to help with the programming [12:55] is it Python? [12:55] I know python & postgresql pretty well [12:55] or... is it ! perl? :) [12:55] DktrKranz: yes [12:55] python, mod_python [12:55] mok01: I can lend a hand too [12:55] * nhandler likes python [12:55] s/python/perl/ [12:56] 5 minutes. [12:56] So, please criticise this summary: [12:56] What I'd need to test, is a copy of the database [12:56] We have a proposal, we have some interested parties: a mock-up will be put up, and some basic work on REVU code, for futher discussion. [12:56] Is that correct? [12:57] yes [12:57] * DktrKranz agrees [12:57] ++ [12:57] mok01, Do you need the live DB, or could you upload a few packages to a test server? [12:57] uhm [12:57] (I can extract the live DB, but don't know how to hand over the gigabytes of unpackaged package files) [12:57] s/unpackaged/unpacked/ [12:58] I was thinking of having a database locally, so I could play with it [12:58] I don't need the packages [12:58] What about having the main DB without files? Is it a problem for REVU? [12:58] Oh, the structure is in the REVU code. [12:58] DktrKranz, The links will all be broken. [12:58] as it's just the front page then throwing an extra python script on the existing REVU for wider testing would be no problem I imagine [12:58] The structure is mostly in the file called index.py [12:58] So, let's finish this with the following actions: [12:58] mok01, Will investigate the REVU code, and play with the DB [12:59] DktrKranz, will investigate hosting options for a testing REVU server [12:59] + [12:59] agreed [12:59] nhandler, will coordinate the process, and bring the discussion back to MOTU when we're reached the next step. [12:59] Did I miss anything? [13:00] sounds about right [13:00] OK. Any other business that needs to be raised for this meeting? [13:00] I'm fine with that [13:00] (so who do we need to get in touch with to get a copy of the database?) === thekorn_ is now known as thekorn [13:01] mok01, nhandler (or I'll help if that breaks) [13:01] Any volunteers to write the minutes and send them out? [13:02] I am not impartial, so it shouldn't be me ;-) [13:02] persia: I don't have access to spooky yet [13:02] I have access, but not to the database [13:02] * DktrKranz raises his hand to write minutes [13:02] DktrKranz, Thank you. [13:02] #endmeeting [13:02] Meeting finished at 07:02. [13:02] not before tomorrow, though :( [13:02] Thanks everyone! I have to run, another meeting coming up! [13:03] I have to move my office to a new location today [13:04] anyway, yay for motu meetings! long time no see :) [13:07] * DktrKranz is off now [14:56] * robbiew is on holiday...so quietly sits in the back of the room ;) [14:57] hello [14:58] o/ [14:59] afternoon [14:59] hello [15:00] hello [15:00] quick, let's release before we find problems [15:00] too late [15:00] heh [15:01] morning, folks [15:02] pgraner, davidm, Riddell, sbeattie, Hobbsee: there? [15:02] im subbing for dendrobates today [15:02] barely [15:02] mm hmm [15:02] slangasek: yep [15:03] zul: ah, hello then :) [15:03] hello [15:04] slangasek, hi [15:05] ok, sounds like we've got everyone we're going to get, let's get started [15:06] #startmeeting [15:06] Meeting started at 09:06. The chair is slangasek. [15:06] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [15:06] [TOPIC] Getting a head start on 8.04.3 point release [15:06] New Topic: Getting a head start on 8.04.3 point release [15:08] so 8.04.2 is behind us (just); I'd like to ask folks to have a look at the bugs that are already targeted to 8.04.3, and if there are some tasks there for members of your team, to please make sure that they get worked on sooner rather than later [15:08] [LINK] https://bugs.launchpad.net/ubuntu/hardy/+bugs?field.milestone=2132 - targeted bugs for 8.04.3 [15:08] LINK received: https://bugs.launchpad.net/ubuntu/hardy/+bugs?field.milestone=2132 - targeted bugs for 8.04.3 [15:09] noted [15:09] ack [15:10] three for foundations I think, plus that base-installer one that TBH may not happen [15:10] ok, on to team reports [15:10] [TOPIC] QA team [15:10] New Topic: QA team [15:10] it's possible that those tasks might not show up on the team assignment pages, due to a launchpadlib bug where the master task is closed. [15:11] sbeattie: anything you want to cover on this, since heno's not here? [15:11] not much, davmor2 is doing smoke testing, anything to say? [15:11] https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/314263 has hit people filing apport bugs. [15:11] Launchpad bug 314263 in glib2.0 "regression - URIs opened with firefox %u load as local files (file:///...)" [High,Confirmed] [15:12] so it'd be nice to get that squashed asap. [15:12] Chris Coulson is debugging that ATM, and he found the reason [15:12] sbeattie: noted; that one's on the hit list [15:12] not a solution yet, though (just told me 20 mins ago) [15:13] [TOPIC] Desktop team [15:13] New Topic: Desktop team [15:13] okay, otherwise I don't have anything to say here, I just realized 5 min ago that heno was traveling. [15:13] rickspencer3: hi [15:13] hi [15:13] sbeattie: ack, thanks [15:14] the desktop team report is at https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus; want me to paste it in here, or read it on the wiki? [15:14] rickspencer3: we have a long list of Desktop bugs; I don't know that we need to go over each one, but if there are any that there's relevant status that should be discussed? [15:14] For the record, i think i understand that bug completely now pitti. i'm going to try and write a patch for it and send it upstream [15:15] the oem-config one on the desktop list may well be foundations [15:15] I think that we are on top of them [15:15] I've been working my way up to looking at it today (but got sidetracked into another critical bug along the way) [15:15] [ACTION] chriscoulson to fix bug #314263 so GNOME URI passing works again [15:15] ACTION received: chriscoulson to fix bug #314263 so GNOME URI passing works again [15:15] Launchpad bug 314263 in glib2.0 "regression - URIs opened with firefox %u load as local files (file:///...)" [High,Confirmed] https://launchpad.net/bugs/314263 [15:15] slangasek: I dont' think we actually need to discuss any of the bugs; it's mainly a status update [15:15] and the status is covered on our wiki [15:15] however, I would be happy to discuss if it seems useful [15:15] [LINK] Desktop team summary at https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus [15:15] LINK received: Desktop team summary at https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus [15:16] pitti: are nvidia/fglrx driver releases expected in the reasonably short term? [15:16] (i.e. do we have contacts who can speak to that?) [15:16] rickspencer3: I was happy to make some headway on bug #321311 this morning; the severity is reduced for me now, but if this affects /anyone/ using IM, then CJK users are affected, so I think we should treat it as critical for now? [15:16] Launchpad bug 321311 in gtk+2.0 "gnome-screensaver dialog helper spins indefinitely, never unlocks the session, when GTK_IM_MODULE is set" [Critical,Confirmed] https://launchpad.net/bugs/321311 [15:16] I can't say, TBH [15:17] I'll ask tseliot/bryce [15:17] ArneGoetje: can you test bug #321311 with whatever the default CJK IMs are? [15:17] slangasek: ack on the severity rating for 321311 [15:17] slangasek: I think I got this bug without GTK_IM* set, and others confirmed this as well [15:18] cjwatson: I happened to have an out-of-band conversation with keithp last night, it sounds like one of the two (fglrx, IIRC) is on-track for a release [15:18] cjwatson: I think that fglrx may come in fairly late for Jaunty, as we are putting the same switcheroo for -ati into place in case it comes to that [15:18] rickspencer3: deja vu all over again [15:18] tseliot works on the nvidia drivers right now [15:18] as a contingency measure [15:18] slangasek: ok, that's good [15:18] so they might make it to alpha4 [15:18] [ACTION] slangasek to follow up with bryce regarding binary driver status [15:18] ACTION received: slangasek to follow up with bryce regarding binary driver status [15:18] apparently new upstream releases just went out [15:18] cjwatson: yes, except this time I think there is already a way to handle the issue in place, so it's not so risky [15:19] pitti: oh, nice [15:19] slangasek: so make that for ati [15:19] https://bugs.launchpad.net/bugs/320666 [15:19] Launchpad bug 320666 in gnome-screensaver "gnome-screensaver fails to unlock after gtk 2.15.0 upgrade" [Undecided,Confirmed] [15:20] [ACTION] slangasek to follow up on bug #320666 to find out why users without GTK_IM_MODULE set are also affected [15:20] ACTION received: slangasek to follow up on bug #320666 to find out why users without GTK_IM_MODULE set are also affected [15:20] Launchpad bug 320666 in gnome-screensaver "gnome-screensaver fails to unlock after gtk 2.15.0 upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/320666 [15:22] nothing we need to discuss as far as the Desktop specs? [15:22] my biggest concern right now is landing the DX/OLS stuff [15:22] rickspencer3: you seem to be more up to date than me for that? [15:22] yes [15:22] right, I was just noticing that was the first item - should Julian have a standing invite to release meetings as well? [15:23] they are packaging code drop #2 today, so should be available for us on Monday [15:23] slangasek: I think dbarth might be more appropriate than julian [15:23] though julian does own some deliverables such as art, etc... that you might want to be tracking [15:24] [ACTION] robbiew to add dbarth to the list of standing invites for release meetings [15:24] ACTION received: robbiew to add dbarth to the list of standing invites for release meetings [15:24] let's add dbarth for now, hopefully he can speak for Julian and we only need to lose 1.5 man hours instead of 3 :-) [15:24] So we should have the notification system well on the way to being done next week, and the messaging indicator is partly working and there is a pidgin IM plugin for it that is working [15:25] slangasek: done [15:25] \o/ [15:25] I don't know how far they have gotten on the KDE parts, though [15:25] I think they are giving themselves a deadline of next Friday to see if they will try to get NS/MI ready for Kubuntu Jaunty [15:25] ok [15:26] hth [15:26] yes, thanks [15:26] let's move on then [15:26] davidm is on a call, so let's skip Mobile for now [15:27] [TOPIC] Kernel team [15:27] New Topic: Kernel team [15:27] pgraner: hi [15:27] slangasek: hello [15:27] slangasek: We are on track for all of the specs and other action items [15:28] slangasek: our big deliverables are improved suspend and resume, ext4 integration, kernel crashdumps and kernel oops reporting... [15:28] slangasek: as stated all are exactly where they should be for this point in the cycle [15:29] pgraner: great! what are the other action items as you see them? :) I put the bugs in the agenda that are on my radar, but I know your team normally works from ogasawara's list [15:29] e.g., is bug #317781 getting investigation? [15:29] Launchpad bug 317781 in linux "Ext4 data loss" [High,Triaged] https://launchpad.net/bugs/317781 [15:29] slangasek: starting on A5 we move to working strictly off the milestoned bug list, so if people need things looked at or fixed thats our list [15:30] slangasek: yes it is... there is not a fix upstream yet. They think its a combo of some ext4 default settings and destop lib (kde noted by name) holding a ton of files open at run time [15:30] mm, generally speaking that's not advisable because the milestoned list for the alphas will be rather thin, as it's intended to consist of only those bugs that are blockers for the milestone [15:31] Is the libdrm header issue and the ports versioning problem on the list? [15:31] pgraner: can you make sure that * [15:31] https://bugs.launchpad.net/ubuntu/jaunty/+bugs [15:31] slangasek: we are adding all the bugs there so we have one place to look at. currently looking across multiple lists causes bug loss for us as witnessed by Intrepid [15:31] is also being tracked generally? [15:31] ScottK: it is [15:32] Great, because that's blocking a lot of stuff. [15:32] slangasek: I will start looking at it and adding them to the milestone bugs if not we don't have a deadline to try and get answers/fixes [15:33] pgraner: ideally, the alpha-* milestoned bugs will get knocked out early and then you can draw on the jaunty pool - that way the hard bugs that don't block the alphas don't get left until right before RC [15:33] slangasek: one would think [15:33] pgraner: ok, I think we should discuss this further afterwards [15:33] [ACTION] slangasek and pgraner to discuss kernel team milestoning/workflow [15:33] ACTION received: slangasek and pgraner to discuss kernel team milestoning/workflow [15:33] slangasek: I'm trying to get it so that I know what will land when and if not people know aobut it [15:34] slangasek: we can talk next week [15:34] ok [15:34] slangasek: your buying the beer :-) [15:34] :-) [15:35] one other action item for the coming week, that we discussed previously [15:35] [ACTION] pgraner to provide a "kernel to userspace" communique describing relevant userspace-affecting changes for this cycle [15:35] ACTION received: pgraner to provide a "kernel to userspace" communique describing relevant userspace-affecting changes for this cycle [15:35] delegate as needed, of course :) [15:35] slangasek: of course :-) [15:35] anything else to cover, or shall we move on? [15:35] slangasek: I'm good [15:36] [TOPIC] Mobile team [15:36] New Topic: Mobile team [15:36] davidm: hi [15:36] hi [15:36] hey, I'm still here actually [15:36] lool: hi as well, if you have more to add [15:36] :) [15:36] (I thought I wouldn't make it) [15:36] Ah lool take it away [15:36] So hmm I'll just repeat what I sent to slangasek via email; overview of what we work on for A4: [15:37] - general focus on armel and UNR [15:37] - target of getting at least an installable armel image, versatile [15:37] - lots of UNR churn lately as OEM sent some drops and filed a bunch of [15:37] bugs [15:37] slangasek brought up https://bugs.launchpad.net/bugs/303232 which is on the radar already, but will be discussed at the sprint [15:37] Launchpad bug 303232 in gcc-4.3 "armel gcc default optimisations" [High,Confirmed] [15:37] https://bugs.launchpad.net/bugs/299847 was new to me, and is actually board specific [15:37] Launchpad bug 299847 in libipc-sharelite-perl "armel build failure (without ignoring testsuite results)" [High,Triaged] [15:37] We woudl need the porter marvell board to diagnose further I'm afraid [15:38] we have rimu now [15:38] We do? great [15:38] Adam brought it up last night [15:38] lool, porter up as of last night [15:38] Concerning specs status, some are done while others are not started, so it's a mixed bag; I don't think we should look at them into too much details right now [15:39] lool: shall I give you an action to follow up on the marvell issue? [15:39] The biggest risk for A4 from us is that we lack resources to test all flavours [15:39] slangasek: If you think its still release critical sure; I had actually in mind to drop its severity [15:40] [ACTION] lool to follow up on bug #299847 on rimu to assess its scope & severity [15:40] ACTION received: lool to follow up on bug #299847 on rimu to assess its scope & severity [15:40] Launchpad bug 299847 in libipc-sharelite-perl "armel build failure (without ignoring testsuite results)" [High,Triaged] https://launchpad.net/bugs/299847 [15:40] Finally, my biggest concern is on whether we will have the time to do testing of all flavours and whether they will be in good shape after the recent churn [15:40]