=== _neversfelde is now known as neversfelde
=== asac_ is now known as asac
persiaAnyone else here for the MOTU Meeting?12:02
* Hobbsee waves12:03
persiaRIght.  Let's wait until we're 5, and get started.12:04
mok01Apparently there's something going on in classroom12:04
persia(more would be better, but less is boring)12:04
persiaYes, the "How to run a Bug Jam" session.12:04
* james_w waves12:04
persiaOK.  Who wants to chair?12:05
* james_w is writing a spec, but will pay attention12:05
* mok01 nominates persia as chair12:05
MootBotMeeting started at 06:05. The chair is persia.12:05
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]12:05
persia[link] https://wiki.ubuntu.com/MOTU/Meetings12:05
MootBotLINK received:  https://wiki.ubuntu.com/MOTU/Meetings12:05
persia[topic] Discussion about REVU12:06
MootBotNew Topic:  Discussion about REVU12:06
persiamok01, You're up.12:06
mok01Well, I've written up a proposal for a revised workflow12:06
persia[LINK] https://wiki.ubuntu.com/REVUWorkflowProposal12:06
MootBotLINK received:  https://wiki.ubuntu.com/REVUWorkflowProposal12:06
mok01In principle it's not very different from what we have today12:07
mok01It's just organized so the flow is clearer to both uploaders and reviewer12:07
mok01and it gives us the possibility of closing for new packages12:08
mok01so we can focus on the ones that are already in the queue12:08
persiaI 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
nhandlermok01: I personally am against the idea of closing REVU for new packages12:08
nhandlerpersia: He had suggested after Feature Freeze iirc12:08
mok01That is one option, but I propose that it is up to the MOTUs to decide12:09
persiaTo 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
persiaIn practice, of course, REVU is mostly completely ignored after FF, so perhaps it doesn't matter.12:09
mok01Yes, the problem is that the influx of new packages is greater than our capacity to process them12:10
nhandlerEven 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 all12:10
nhandlermok01: The same thing could be said about bugs on Launchpad. Should we stop accepting new bug reports?12:10
mok01nhandler: don't be silly12:10
Hobbseenhandler: well, apport does get turned off for crashes in stable releases, for that very reason, fwiw.12:10
mok01Anyway, closing is a minor point.12:11
nhandlerAs for restructuring the lists, I am still a little unclear as to what this is meant to accomplish12:11
mok01According to the proposal, unreviewed uploads will be on it's own list12:12
mok01The packages that have received >= 1 review, move to the "In process" list12:12
mok01and then the progress pretty much like now12:13
nhandlerBut 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 review12:13
nhandlerCurrently, packages with 1 advocation are at the top and easy to see12:13
nhandlerPackages that need work are at the bottom and out of the way12:13
mok01nhandler: ATM, the list is cluttered with completely new uploads and people putting the final touches on their package12:13
nhandlermok01: This is one reason more MOTUs should subscribe to packages12:14
mok01And cluttered by packages that already have an advocate, but the 2nd one has asked for some changes12:14
mok01nhandler: that's voluntary, of course12:15
nhandlermok01: It is, but subscribing to packages that you review would solve a LOT of the problems we currently have12:16
HobbseeQuestion:  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 status12:16
mok01nhandler: I have reviewed a LOT this cycle, you don't need to explain to me how it works12:16
nhandlermok01: These comments are dirrected at you personally, they are just general comments12:17
nhandlerHobbsee: That is my understanding. But I don't think there is any official policy about it yet12:17
mok01nhandler: well, you prefixed your comments with my nick12:17
Hobbseenhandler: because, if that's the case, this will not be such an issue next cycle.12:17
persiaThere's never been a policy about either way.12:17
Hobbseewhich means one could probably advertise for a concerted effort once, and people not getting hit with consistent mails about it being REVU day yet again12:18
mok01Hobbsee: 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 discussion12:18
persiaThe 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
persiaThe way to address this is to edit the wiki, not wait for some decision.12:18
mok01I have drafted a proposal for a getting started page that points people towards bug fixing etc12:19
* DktrKranz waves12:19
* nhandler has to leave12:19
Hobbseemok01: Hurrah!  I agree that it should be discussed separately, but this discussion has that as a dependancy.12:19
mok01Hobbsee: well, not really. We can modify the workflow without such a decision12:20
Hobbseescore :)12:20
mok01IMO it will make reviewing life easier, and we can collectively focus on packages where the uploader is active12:20
mok01Right now, there are > 125 packages in the "needs-review" section, so by stochastics, our effort is spread on all of them at once12:21
mok01Of those 125, I estimate that about half have never receieved a review12:22
mok01So it would be good if they did not appear in the same list12:22
mok01Because then everybody would focus on the 60 or so, and they would get processed quicker12:22
mok01To more satisfaction for all12:23
persiaWell, what's the goal?12:23
persiaI always thought the goal was to get in the most interesting packages that were missing.12:23
persiaFocusing on "active uploaders" doesn't seem to help this goal.12:23
mok01The goal is to get a process where we don't spread ourselves too thin on a very large number of uploads12:23
persiaI'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
mok01persia: my proposal does not rule that out12:24
mok01persia: see use case 412:25
persiaHrm.  I see.12:26
persiaSo 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
persiaMaybe we could just list the category in the table, rather than having separate lists?12:26
mok01That's a matter of layout I guess.12:27
mok01I don't see the point of having a very long cluttered list though12:27
persiaWell, if you're not specifying which should be examined, what part is the clutter?12:28
DktrKranzHaving 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
mok01DktrKranz: exactly12:28
DktrKranz... but are we sure we don't focus too much on "almost ready" packages, discarding "New" packages?12:28
DktrKranzthat's my major issue with it12:29
persiaI don't think the ones that have previously been advocated should be considered those that don't need much review.12:29
mok01There is not much point of having 125 packages waiting for processing12:29
persiaI think those require the *most* detailed review, in case the previous reviewer missed something.12:29
mok01It's better to give the final review to a package to get it moving along the pipeline12:30
DktrKranzIt depends on how much detailed first review was12:30
DktrKranzI try to have a deep review first12:30
DktrKranzjust to make sure major issues come out soon12:30
mok01persia: that's why I have the "Advocate" section, with packages that have 1 advocate.12:30
mok01They stay in that section12:31
mok01and don't go back to Processing unless the advocate removes the vote12:31
DktrKranzit'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
mok01DktrKranz: yes12:31
persiamok01, Would perhaps continuance of advocacy meet that need: so that if someone advocates, the advocacy persists for further uploads?12:32
mok01persia: yes12:32
persiaMy fear there is that a change might mean that I no longer wanted to grant advocacy.12:32
mok01persia: from the logic, that if you've advocated a package at a certain stage, it's ok to improve it12:33
mok01persia: then you could remomve your advocacy12:33
persiaOne 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
persiaYes, 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
mok01persia: you still have that option12:33
mok01persia: you can leave a not to the next reviewer that you want to approve the final pacakge12:34
DktrKranzWhat about have the second reviewer to ask for a confirmation of the first ACK before uploading?12:34
* mok01 propose that we take a look at the REVU list now12:34
MootBotLINK received:  http://revu.ubuntuwire.com/12:34
persiamok01, But then I still get poked, which I don't prefer :(12:35
mok01Then you have to trust your fellow MOTUs12:35
mok01Most of the packages at the top have never received a review.12:36
mok01They were uploaded in november12:36
mok01I have notes that tell me which packages I follow12:37
mok01so I go to the bottom of the list to see if any of those have come back12:37
mok01That is deceitful to the people at the top, who think they are next in line12:38
DktrKranzI 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:38
persiaI'm not sure it's deceitful.  Perhaps we just need to make it more clear that REVU is not a FIFO queue.12:39
DktrKranzand probably will never be12:40
mok01A lot of people just give up and go away with a bad impression of MOTU12:40
mok01Look at the length of the needs-work list12:40
DktrKranzmok01: I think mentors.debian.net have the same issues, packages are not processed regularly, but on a "i-have-time-to-do-some" basis12:41
persiaWell 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
mok01mentors,debian.net = never processed unless you find a sponsor12:41
persiaAnyway, part of the issue is the assumption that just uploading to REVU is a good way to learn.12:41
DktrKranzpeople could be discouraged about long time for a review, but there are several options to speed up things12:41
persiaMany 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
DktrKranzsuch asking in #ubuntu-motu during REVU days12:41
persiaThat was less true in the past, but it certainly discourages me from REVUing things where I don't see the benefit.12:42
mok01DktrKranz: yes, I give priority to people in IRC12:42
mok01persia: you don't have to12:42
persiaPersonally, I'd rather keep REVU *hard*, because I think we don't do enough for the packages we already maintain.12:42
DktrKranzpersia: good point. There are packages which are there just to say "hey, I've packed something!"12:42
persiaAnd discourage people from putting things there unless they really have some need to get it in the distro.12:43
mok01Now, though, we have PPAs and that ought to be able to take the load off REVU12:43
persiaWell, yes, but it's also taken some of the reviewers away.12:43
mok01persia: but that is part of another discussion12:43
persiaSince 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
DktrKranzI don't remember what, but I noticed a package made with ch*ckinst@ll some times ago...12:44
mok01Although I have thoughts about how to choose packages for review, the proposal is ONLY about organizing the web page differently12:44
persiaI guess I just don't see the benefit.12:45
mok01persia: it wont be any worse for you then12:45
mok01OK, so if we look at the top of the REVU page... the packages with the green icons12:46
DktrKranzI'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" packages12:46
mok01they have one advocate. I the next one wants a trivial change, it goes waaaayy down to the bottom of the Needs Review12:47
DktrKranznow, we just can't12:47
nhandlerWhat 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:47
DktrKranznhandler: this would be handled better via "neutral vote", IMHO12:48
DktrKranz"I don't like this, but it's minor and I won't push you back just for a typo"12:49
persiaIt seems there's still an assumption of a FIFO queue.  Do we want that for some reason?12:50
mok01I 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
mok01Sometimes the 2nd advocate asks for a package to be split.12:50
mok01but even so, the package is in pretty good shape12:50
mok01with copyright etc.12:51
DktrKranzmok01: about REVU code change, do changes you propose affect current view of REVU page? Can both variant co-exist?12:51
DktrKranzboth variant = actual display of packages and new way12:52
mok01DktrKranz: uhm... well the web page is just a view of the data base, so I'd think so12:52
DktrKranzso, we can have two pages12:52
DktrKranzjust to see if people like the idea12:52
mok01DktrKranz: Solomonic solution12:53
DktrKranzso, it's just a matter of bring things back to repair12:53
nhandlerDidn't someone have a "testing" version of REVU when they were testing the new theme?12:53
persiaI'd like that.  While I'm not seeing a benefit in the abstract, I might see one with the example.12:53
persiaDoesn't even need to be done in REVU code or live, but just a layout sample.12:53
persianhandler, There's a few of them that were set up.  Dunno of any that are publically available.12:54
DktrKranzif we can have a REVU server up for a while, we can test things and eventually push on main site12:54
DktrKranzI could ask a friend of mine to host the stuff12:54
mok01I am willing to help with the programming12:54
DktrKranzis it Python?12:55
mok01I know python & postgresql pretty well12:55
DktrKranzor... is it ! perl? :)12:55
mok01DktrKranz: yes12:55
mok01python, mod_python12:55
DktrKranzmok01: I can lend a hand too12:55
* nhandler likes python12:55
persia5 minutes.12:56
persiaSo, please criticise this summary:12:56
mok01What I'd need to test, is a copy of the database12:56
persiaWe 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
persiaIs that correct?12:56
* DktrKranz agrees12:57
persiamok01, Do you need the live DB, or could you upload a few packages to a test server?12:57
persia(I can extract the live DB, but don't know how to hand over the gigabytes of unpackaged package files)12:57
mok01I was thinking of having a database locally, so I could play with it12:58
mok01I don't need the packages12:58
DktrKranzWhat about having the main DB without files? Is it a problem for REVU?12:58
persiaOh, the structure is in the REVU code.12:58
persiaDktrKranz, The links will all be broken.12:58
james_was it's just the front page then throwing an extra python script on the existing REVU for wider testing would be no problem I imagine12:58
mok01The structure is mostly in the file called index.py12:58
persiaSo, let's finish this with the following actions:12:58
persiamok01, Will investigate the REVU code, and play with the DB12:58
persiaDktrKranz, will investigate hosting options for a testing REVU server12:59
persianhandler, will coordinate the process, and bring the discussion back to MOTU when we're reached the next step.12:59
persiaDid I miss anything?12:59
mok01sounds about right13:00
persiaOK.  Any other business that needs to be raised for this meeting?13:00
DktrKranzI'm fine with that13:00
mok01(so who do we need to get in touch with to get a copy of the database?)13:00
=== thekorn_ is now known as thekorn
persiamok01, nhandler (or I'll help if that breaks)13:01
persiaAny volunteers to write the minutes and send them out?13:01
mok01I am not impartial, so it shouldn't be me ;-)13:02
nhandlerpersia: I don't have access to spooky yet13:02
mok01I have access, but not to the database13:02
* DktrKranz raises his hand to write minutes13:02
persiaDktrKranz, Thank you.13:02
MootBotMeeting finished at 07:02.13:02
DktrKranznot before tomorrow, though :(13:02
mok01Thanks everyone! I have to run, another meeting coming up!13:02
DktrKranzI have to move my office to a new location today13:03
DktrKranzanyway, yay for motu meetings! long time no see :)13:04
* DktrKranz is off now13:07
* robbiew is on holiday...so quietly sits in the back of the room ;)14:56
Riddellquick, let's release before we find problems15:00
cjwatsontoo late15:00
slangasekmorning, folks15:01
slangasekpgraner, davidm, Riddell, sbeattie, Hobbsee: there?15:02
zulim subbing for dendrobates today15:02
Riddellmm hmm15:02
pgranerslangasek: yep15:02
slangasekzul: ah, hello then :)15:03
davidmslangasek, hi15:04
slangasekok, sounds like we've got everyone we're going to get, let's get started15:05
MootBotMeeting started at 09:06. The chair is slangasek.15:06
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]15:06
slangasek[TOPIC] Getting a head start on 8.04.3 point release15:06
MootBotNew Topic:  Getting a head start on 8.04.3 point release15:06
slangasekso 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 later15:08
slangasek[LINK] https://bugs.launchpad.net/ubuntu/hardy/+bugs?field.milestone=2132 - targeted bugs for 8.04.315:08
MootBotLINK received:  https://bugs.launchpad.net/ubuntu/hardy/+bugs?field.milestone=2132 - targeted bugs for 8.04.315:08
cjwatsonthree for foundations I think, plus that base-installer one that TBH may not happen15:10
slangasekok, on to team reports15:10
slangasek[TOPIC] QA team15:10
MootBotNew Topic:  QA team15:10
sbeattieit'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:10
slangaseksbeattie: anything you want to cover on this, since heno's not here?15:11
sbeattienot much, davmor2 is doing smoke testing, anything to say?15:11
sbeattiehttps://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/314263 has hit people filing apport bugs.15:11
ubottuLaunchpad bug 314263 in glib2.0 "regression - URIs opened with firefox %u load as local files (file:///...)" [High,Confirmed]15:11
sbeattieso it'd be nice to get that squashed asap.15:12
pittiChris Coulson is debugging that ATM, and he found the reason15:12
slangaseksbeattie: noted; that one's on the hit list15:12
pittinot a solution yet, though (just told me 20 mins ago)15:12
slangasek[TOPIC] Desktop team15:13
MootBotNew Topic:  Desktop team15:13
sbeattieokay, otherwise I don't have anything to say here, I just realized 5 min ago that heno was traveling.15:13
slangasekrickspencer3: hi15:13
slangaseksbeattie: ack, thanks15:13
pittithe 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
slangasekrickspencer3: 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
pittiFor the record, <chrisccoulson> i think i understand that bug completely now pitti. i'm going to try and write a patch for it and send it upstream15:14
cjwatsonthe oem-config one on the desktop list may well be foundations15:15
rickspencer3I think that we are on top of them15:15
cjwatsonI've been working my way up to looking at it today (but got sidetracked into another critical bug along the way)15:15
slangasek[ACTION] chriscoulson to fix bug #314263 so GNOME URI passing works again15:15
MootBotACTION received:  chriscoulson to fix bug #314263 so GNOME URI passing works again15:15
ubottuLaunchpad bug 314263 in glib2.0 "regression - URIs opened with firefox %u load as local files (file:///...)" [High,Confirmed] https://launchpad.net/bugs/31426315:15
pittislangasek: I dont' think we actually need to discuss any of the bugs; it's mainly a status update15:15
rickspencer3and the status is covered on our wiki15:15
rickspencer3however, I would be happy to discuss if it seems useful15:15
slangasek[LINK] Desktop team summary at https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus15:15
MootBotLINK received:  Desktop team summary at https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus15:15
cjwatsonpitti: are nvidia/fglrx driver releases expected in the reasonably short term?15:16
cjwatson(i.e. do we have contacts who can speak to that?)15:16
slangasekrickspencer3: 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
ubottuLaunchpad 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/32131115:16
pittiI can't say, TBH15:16
pittiI'll ask tseliot/bryce15:17
slangasekArneGoetje: can you test bug #321311 with whatever the default CJK IMs are?15:17
rickspencer3slangasek: ack on the severity rating for 32131115:17
loolslangasek: I think I got this bug without GTK_IM* set, and others confirmed this as well15:17
slangasekcjwatson: 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 release15:18
rickspencer3cjwatson: 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 that15:18
cjwatsonrickspencer3: deja vu all over again15:18
pittitseliot works on the nvidia drivers right now15:18
rickspencer3as a contingency measure15:18
cjwatsonslangasek: ok, that's good15:18
pittiso they might make it to alpha415:18
slangasek[ACTION] slangasek to follow up with bryce regarding binary driver status15:18
MootBotACTION received:  slangasek to follow up with bryce regarding binary driver status15:18
pittiapparently new upstream releases just went out15:18
rickspencer3cjwatson: yes, except this time I think there is already a way to handle the issue in place, so it's not so risky15:18
slangasekpitti: oh, nice15:19
pittislangasek: so make that for ati15:19
ubottuLaunchpad bug 320666 in gnome-screensaver "gnome-screensaver fails to unlock after gtk 2.15.0 upgrade" [Undecided,Confirmed]15:19
slangasek[ACTION] slangasek to follow up on bug #320666 to find out why users without GTK_IM_MODULE set are also affected15:20
MootBotACTION received:  slangasek to follow up on bug #320666 to find out why users without GTK_IM_MODULE set are also affected15:20
ubottuLaunchpad bug 320666 in gnome-screensaver "gnome-screensaver fails to unlock after gtk 2.15.0 upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/32066615:20
slangaseknothing we need to discuss as far as the Desktop specs?15:22
pittimy biggest concern right now is landing the DX/OLS stuff15:22
pittirickspencer3: you seem to be more up to date than me for that?15:22
slangasekright, I was just noticing that was the first item - should Julian have a standing invite to release meetings as well?15:22
rickspencer3they are packaging code drop #2 today, so should be available for us on Monday15:23
rickspencer3slangasek: I think dbarth might be more appropriate than julian15:23
rickspencer3though julian does own some deliverables such as art, etc... that you might want to be tracking15:23
slangasek[ACTION] robbiew to add dbarth to the list of standing invites for release meetings15:24
MootBotACTION received:  robbiew to add dbarth to the list of standing invites for release meetings15:24
slangaseklet'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
rickspencer3So 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 working15:24
robbiewslangasek: done15:25
rickspencer3I don't know how far they have gotten on the KDE parts, though15:25
rickspencer3I think they are giving themselves a deadline of next Friday to see if they will try to get NS/MI ready for Kubuntu Jaunty15:25
slangasekyes, thanks15:26
slangaseklet's move on then15:26
slangasekdavidm is on a call, so let's skip Mobile for now15:26
slangasek[TOPIC] Kernel team15:27
MootBotNew Topic:  Kernel team15:27
slangasekpgraner: hi15:27
pgranerslangasek: hello15:27
pgranerslangasek: We are on track for all of the specs and other action items15:27
pgranerslangasek: our big deliverables are improved suspend and resume, ext4 integration, kernel crashdumps and kernel oops reporting...15:28
pgranerslangasek: as stated all are exactly where they should be for this point in the cycle15:28
slangasekpgraner: 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 list15:29
slangaseke.g., is bug #317781 getting investigation?15:29
ubottuLaunchpad bug 317781 in linux "Ext4 data loss" [High,Triaged] https://launchpad.net/bugs/31778115:29
pgranerslangasek: starting on A5 we move to working strictly off the milestoned bug list, so if people need things looked at or fixed thats our list15:29
pgranerslangasek: 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 time15:30
slangasekmm, 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 milestone15:30
ScottKIs the libdrm header issue and the ports versioning problem on the list?15:31
slangasekpgraner: can you make sure that     *15:31
slangasek      https://bugs.launchpad.net/ubuntu/jaunty/+bugs15:31
pgranerslangasek: 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 Intrepid15:31
slangasekis also being tracked generally?15:31
pgranerScottK: it is15:31
ScottKGreat, because that's blocking a lot of stuff.15:32
pgranerslangasek: 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/fixes15:32
slangasekpgraner: 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 RC15:33
pgranerslangasek: one would think15:33
slangasekpgraner: ok, I think we should discuss this further afterwards15:33
slangasek[ACTION] slangasek and pgraner to discuss kernel team milestoning/workflow15:33
MootBotACTION received:  slangasek and pgraner to discuss kernel team milestoning/workflow15:33
pgranerslangasek: I'm trying to get it so that I know what will land when and if not people know aobut it15:33
pgranerslangasek: we can talk next week15:34
pgranerslangasek: your buying the beer :-)15:34
slangasekone other action item for the coming week, that we discussed previously15:35
slangasek[ACTION] pgraner to provide a "kernel to userspace" communique describing relevant userspace-affecting changes for this cycle15:35
MootBotACTION received:  pgraner to provide a "kernel to userspace" communique describing relevant userspace-affecting changes for this cycle15:35
slangasekdelegate as needed, of course :)15:35
pgranerslangasek: of course :-)15:35
slangasekanything else to cover, or shall we move on?15:35
pgranerslangasek: I'm good15:35
slangasek[TOPIC] Mobile team15:36
MootBotNew Topic:  Mobile team15:36
slangasekdavidm: hi15:36
loolhey, I'm still here actually15:36
slangaseklool: hi as well, if you have more to add15:36
lool(I thought I wouldn't make it)15:36
davidmAh lool take it away15:36
loolSo hmm I'll just repeat what I sent to slangasek via email; overview of what we work on for A4:15:36
lool - general focus on armel and UNR15:37
lool - target of getting at least an installable armel image, versatile15:37
lool - lots of UNR churn lately as OEM sent some drops and filed a bunch of15:37
lool   bugs15:37
loolslangasek brought up https://bugs.launchpad.net/bugs/303232 which is on the radar already, but will be discussed at the sprint15:37
ubottuLaunchpad bug 303232 in gcc-4.3 "armel gcc default optimisations" [High,Confirmed]15:37
loolhttps://bugs.launchpad.net/bugs/299847 was new to me, and is actually board specific15:37
ubottuLaunchpad bug 299847 in libipc-sharelite-perl "armel build failure (without ignoring testsuite results)" [High,Triaged]15:37
loolWe woudl need the porter marvell board to diagnose further I'm afraid15:37
cjwatsonwe have rimu now15:38
loolWe do? great15:38
cjwatsonAdam brought it up last night15:38
davidmlool, porter up as of last night15:38
loolConcerning 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 now15:38
slangaseklool: shall I give you an action to follow up on the marvell issue?15:39
loolThe biggest risk for A4 from us is that we lack resources to test all flavours15:39
loolslangasek: If you think its still release critical sure; I had actually in mind to drop its severity15:39
slangasek[ACTION] lool to follow up on bug #299847 on rimu to assess its scope & severity15:40
MootBotACTION received:  lool to follow up on bug #299847 on rimu to assess its scope & severity15:40
ubottuLaunchpad bug 299847 in libipc-sharelite-perl "armel build failure (without ignoring testsuite results)" [High,Triaged] https://launchpad.net/bugs/29984715:40
loolFinally, 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 churn15:40
slangaseklool: what are the set of flavors that are relevant for A4?15:40
loolMID, UNR, and armel/versatile/d-i are the ones we will test15:40
loolslangasek: Perhaps we should list some d-i armel images in the tracker15:40
cjwatsonwe'll need to get the last added to iso.qa15:40
loolI think that's all I ahd15:40
loolThere's a kernel upload pending for us15:40
slangasek[ACTION] slangasek to ask armel/versatile/d-i to be added to ISO tracker15:41
MootBotACTION received:  slangasek to ask armel/versatile/d-i to be added to ISO tracker15:41
loolcjwatson grabbed it already15:41
cjwatsons/pending/in the queue/15:41
cjwatsond-i needed a rebuild anyway, so I'll do that Monday at the latest15:41
slangaseklool: how testable are MID and UNR by people on random non-mobile hardware; are there instructions linked from the ISO tracker that explain what needs tested?15:41
cjwatsonversatile is testable in qemu (I know you didn't ask, so you may already know this, but just for the record)15:42
loolslangasek: MID is easy to test15:42
loolslangasek: it can be tested in qemu15:42
loollvm etc.15:42
ograunr needs composite15:42
loolslangasek: UNR requires GL though15:42
loolSo it might be something we could do with vbox in the future, but right now it requires hardware15:43
slangasekis there a test case description at least for MID on the ISO tracker?15:43
loolWe will have at least one or two netbooks which we will probably use for testing15:43
slangasekand if not, would now be a good time for someone to write one, so that the community can help with MID testing for A4?15:43
loolI don't remember; MID is already in the tracker though15:43
davidmeee PC 700 -900 -1000 Acer Aspire One and Samsung NC1015:44
davmor2slangasek: I have an AAO to test on15:44
slangaseklool: yes - but currently the community testers punt on it and expect the Mobile team to do their own testing :)  If we're to change that, we need documentation15:44
loolslangasek: I guess we could write that; however in general we're trying to keep MID in decent shape while spending most of our efforts on the other flavours15:44
davidmThat will be the hardware for UNR, PO issued for same15:44
loolslangasek: Ok; give us an action and I'll either document or delegate that  :-)15:44
ograQ1U is fine for unr testing as well btw15:44
slangasek[ACTION] lool, davidm to provide MID test case documentation for the ISO tracker15:45
MootBotACTION received:  lool, davidm to provide MID test case documentation for the ISO tracker15:45
slangasekanything else?15:45
loolslangasek: err action to add armel to tracker15:46
loolOr I missed it15:46
slangasekI actioned myself for that15:46
loolah no it's there, sorry15:46
slangasek[TOPIC] Foundations team15:46
MootBotNew Topic:  Foundations team15:46
cjwatsonok, quick summary of bugs from the agenda:15:46
cjwatson44194: this bug is a bit of a disaster area due to several people taking confrontational stances; I suggest that those of us at the sprint assess it calmly, taking into account the views raised in the bug15:46
cjwatson59695: I believe the remaining part (pm-utils) is slangasek's, and is reasonably well-understood15:47
cjwatson272314: fixed15:47
cjwatson309215: slangasek already targeted to alpha-6, which I think is reasonable15:47
cjwatson311228: fix committed15:47
cjwatson317068: I believe evand is well in progress on this one; worst case we'll fix it on Monday at the sprint15:47
cjwatsonalso, I've been looking into the oem-config Kubuntu bug from the desktop section, but haven't got far enough to venture a cause yet (largely due to fat-fingering and test-installing Ubuntu by mistake)15:47
cjwatsonhowever, I did run into bug 303515 in the process15:47
ubottuLaunchpad bug 303515 in pam "passwd indicates password updated although it wasn't" [Critical,Triaged] https://launchpad.net/bugs/30351515:47
cjwatsonI'm somewhat concerned that that was previously triaged to Low importance and largely ignored15:47
cjwatson(it was on shadow up to now, I think it's actually pam though)15:48
slangasekI think that's a dupe of another bug that was already reported against pam15:48
slangasekwhich wasn't marked 'low', but takes a massive surgery on libpam to fix15:48
cjwatsonI looked and couldn't fine it15:48
cjwatsonoh, bug 198730?15:49
ubottuLaunchpad bug 198730 in pam "a "new password" failure in a requisite PAM module does not prevent setting that password" [Undecided,New] https://launchpad.net/bugs/19873015:49
slangasekI don't think so15:49
cjwatsonno, maybe not15:49
slangasekthe problem is the PAM stack returning the wrong error code and passwd printing a confusing message15:49
slangasekwe can discuss that after the meeting in more depth?15:50
cjwatsonwrong error code, namely PAM_SUCCESS? :-)15:50
cjwatsonhappy to, it seems to be a regression versus Debian unless I miss my guess, I assume due to the new PAM configuration layout15:50
slangasek[ACTION] slangasek and cjwatson to discuss/brainstorm on bug #30351515:51
MootBotACTION received:  slangasek and cjwatson to discuss/brainstorm on bug #30351515:51
ubottuLaunchpad bug 303515 in pam "passwd indicates password updated although it wasn't" [Critical,Triaged] https://launchpad.net/bugs/30351515:51
slangasekare there any other bugs that ought to be escalated for Foundations that we haven't yet?15:51
cjwatsonI'm paying attention to qa-jaunty-foundations as well as a general rule15:51
cjwatsonI don't *think* there are any that badly need escalation there, but will check15:52
cjwatsonregarding specs, Robbie is more up-to-date than I am; we are behind on spec writing/review though, and trying to catch up15:52
slangasek44194> fwiw, I was thinking to fix this by just moving the stuff to /lib and be done with it :)15:52
cjwatsonyes, although that's hairy with regard to state directories15:52
cjwatsonif /usr is separate, /var may well be too15:52
slangasekyes, I'm planning to finish all my spec drafting today... :)15:53
cjwatsonI gathered, though, that the problem was not merely that /usr was unmounted, but also that filesystems were potentially not yet writable15:53
* robbiew was just about to "remind" slangasek15:53
cjwatsonbut I only saw this bug for the first time today15:53
slangasekcjwatson: I think there are provisions for early write to /var with bind mount twiddling; we can diagnose further after the meeting tho15:54
cjwatsonI'm running out of time in my day and lots to do still, so if "after the meeting" is "in Berlin", that's great15:54
* slangasek nods15:54
slangasekrobbiew: anything you want to add about individual specs, or should we move on?15:55
robbiewnope...move on15:55
slangasek[TOPIC] Server team15:55
MootBotNew Topic:  Server team15:55
slangasekzul: hi15:55
cjwatsonI've run into several problems with LVM/RAID/encryption that indicate possible testing weaknesses or failure to escalate bugs, so we probably need to make a concerted effort there15:55
cjwatson(sorry, didn't mean to overflow our slot, lag)15:55
zulnothing to really report on our side we continue to reduce the size of the seeds so that the cloud computing stuff can fit on there15:56
slangasekzul: I managed to find a pair of bugs that fall in the server team's domain, posted to the agenda - which is at https://wiki.ubuntu.com/ReleaseTeam/Meeting/2009-01-30 if you don't have it15:57
slangasekbug #305264 needs a judgement call from the server team (either generally, or from the security guys)15:57
ubottuLaunchpad bug 305264 in openldap "gnutls regression: failure in certificate chain validation" [Undecided,Invalid] https://launchpad.net/bugs/30526415:57
zulok ill nudge the security team to look at it, and ill upload the nmap one today15:58
slangasekok, great15:58
slangasekanything else you want to cover, or shall we keep going so we can get out of here early? :)15:59
zulkeep on going :)15:59
slangasek[TOPIC] MOTU15:59
MootBotNew Topic:  MOTU15:59
slangasekScottK: hi15:59
ScottKA couple of areas worth mentioning here I think.15:59
ScottKThere is an ongoing discussion about Java packaging that feels a lot like the precursors to the Ruby Gems fiasco we had last cycle.16:00
ScottKI think we are a long way from consensus on it and I would really hope we avoid premature uploads.16:00
* slangasek nods16:01
ScottKThe only other significant issue is we got pushed into a ghc6 transition by accident.16:01
slangasekhmm, was the 'accident' before or after the round of ghc6 sync requests?16:01
ScottKSomeone didn't understand how those packages relate to each other and so they are going to have to be rebuilt.16:01
ScottKIt was before, I'm pretty sure.16:01
ScottKIt's in progress now.16:02
ScottKI doubt it'll be done by feature freeze, but I don't think it'll be an issue in the end.16:02
cjwatsonthe accident was before16:02
slangasekScottK: something we should revisit the status on next meeting?16:02
cjwatsonI had thought those sync requests cleaned up most of it, actually16:03
ScottKWe're going to have our initial team meeting next week and so after that I should have more to say.16:03
slangasek"initial team meeting" - for which team?16:03
slangasekMOTU release?16:03
ScottKInitial for this cycle.16:03
ScottKWe'll have 3 returning and one or two new people.16:03
ScottKI'll see what i can do about getting a status on ghc6 for the next meeting.16:04
slangasek[ACTION] ScottK to report back on the status of ghc6 transition16:04
MootBotACTION received:  ScottK to report back on the status of ghc6 transition16:04
ScottKThat's all I have unless anyone else has something.16:04
slangasekgood to hear that motu-release is still healthy, both with ongoing committments and new blood :)16:04
slangasekthanks for the report16:05
slangasek[TOPIC] General feature update16:05
MootBotNew Topic:  General feature update16:05
slangasekeverything here /should/ already be covered by the per-team reports, but if this jogs anyone's memory...16:05
ScottKWe landed KDE 4.2.0 in Kubuntu Jaunty on release day.16:06
ScottKThat didn't get mentioned so far...16:06
pittiwhat's the response so far?16:06
slangasekyay :)16:06
ScottKVery positive.16:06
pittia big "ooooh, so much better than 4.1!!!1!"?16:06
Riddellplanet gnome was impressed :)16:07
ScottKMore like "This is the KDE4 I've been waiting for"16:07
rickspencer3great news16:07
slangasekScottK: oh, on the subject of Kubuntu, is bug #289907 on the radar of anyone who has upload rights?16:07
ubottuLaunchpad bug 289907 in qt4-x11 "Event handler drops some events when rate of incoming events is high" [Undecided,In progress] https://launchpad.net/bugs/28990716:07
cjwatsonseveral installer bits and pieces (oem-config-server, server-pre-installation) likely to be landing piecemeal over the next couple of weeks16:07
ScottKWe've also got Intrepid packages in a PPA to get wider exposure.16:07
cjwatsonmanual package selection in the server installer is a big one there, assuming that I actually manage to get it working16:08
* ScottK looks at Riddell for the qt4 bug?16:08
RiddellI can take a look at that16:08
slangasek[ACTION] Riddell to follow up on bug #28990716:09
MootBotACTION received:  Riddell to follow up on bug #28990716:09
ubottuLaunchpad bug 289907 in qt4-x11 "Event handler drops some events when rate of incoming events is high" [Undecided,In progress] https://launchpad.net/bugs/28990716:09
slangasek[TOPIC] Known regressions16:09
MootBotNew Topic:  Known regressions16:09
slangasek[LINK] https://bugs.launchpad.net/ubuntu/+bugs?field.tag=regression-potential16:09
MootBotLINK received:  https://bugs.launchpad.net/ubuntu/+bugs?field.tag=regression-potential16:09
slangasek[LINK] http://www.ubuntu.com/testing/jaunty/alpha3#Known%20issues16:09
MootBotLINK received:  http://www.ubuntu.com/testing/jaunty/alpha3#Known%20issues16:09
cjwatsonthe IPv6 one is something I've been trying to puzzle out16:10
cjwatsonbug 31321816:10
ubottuLaunchpad bug 313218 in linux "IPV6 causes slow internet access" [Undecided,Confirmed] https://launchpad.net/bugs/31321816:10
slangasekI triaged the bugs from both of these sources before the meeting and doled the highest-priority ones out to teams, so this is mostly a PSA for them16:10
cjwatsonI am not convinced that 313218 is a kernel bug, since glibc is supposed to deal with this situation16:11
slangasek(a bunch of the bugs on there need to be retagged as regression-release now for 8.10...)16:11
slangasekfyi, we've had pretty good turnaround too on the errataed bugs from alpha3, with just one or two that haven't been fixed plus the expected binary driver stragglers16:11
sbeattieslangasek: I'll do the retagging16:12
slangasekcjwatson: do you want to take an action on that one?16:12
slangasek[ACTION] sbeattie to clean up regression-proposed tags on bugs present in intrepid16:12
MootBotACTION received:  sbeattie to clean up regression-proposed tags on bugs present in intrepid16:12
cjwatsonyeah, why not16:13
slangasek[ACTION] cjwatson to follow up on bug #31321816:13
MootBotACTION received:  cjwatson to follow up on bug #31321816:13
ubottuLaunchpad bug 313218 in linux "IPV6 causes slow internet access" [Undecided,Confirmed] https://launchpad.net/bugs/31321816:13
ScottKOne thing I think worth mentioning wrt known issues is Kmail/Akonadi and Amarok are now co-installable again.  Thanks to the Server Team for working with Kubuntu on repackaging Mysql 5.0/5.1 to make them co-installable and minimize desktop footprint.16:13
* pitti sobs16:14
* rickspencer3 pats pitti's shoulder16:14
slangasekah, congrats to server team and the kubuntu folks there16:14
pitti"minimize desktop footprint" is such an euphemism here... :-(16:14
* ScottK hands pitti a tissue.16:14
slangasek[TOPIC] Hardware testing16:15
MootBotNew Topic:  Hardware testing16:15
slangasekincluding here for completeness, but I don't think there's anything to report yet16:15
slangasek(nor do we have heno here to do the reporting)16:15
cjwatsonpitti: gconf/gettext, right? :-)16:15
slangasek[TOPIC] ISO size16:15
MootBotNew Topic:  ISO size16:15
pitticjwatson: already told slangasek about that gem :)16:16
slangasekI'm gratified to see that the latest OOo upload did *not* push Ubuntu CDs oversize :-)16:16
slangasekunfortunately, we've managed to push the *DVD* oversized at some point!16:16
pittiI'm also in conversation with Celso about shipping the NGOME help in langpacks16:16
slangasekso if anyone knows of things that should just plain be tossed out of main... nominate them loudly :)16:16
pittiif we are very lucky, the new custom upload format for that can be implemented quickly in Soyuz16:16
pittibut I wouldn't hold my breath for that for Jaunty16:17
slangasekanything else we've missed?16:17
slangasekassuming there'll be plenty of other opportunities still for one-on-one conversations :)16:18
MootBotMeeting finished at 10:18.16:18
slangasekthanks, all!16:18
pittithanks everyone16:18
=== dholbach_ is now known as dholbach
=== thekorn_ is now known as thekorn
=== RainCT_ is now known as RainCT
=== _neversfelde is now known as neversfelde
=== cody-somerville_ is now known as cody-somerville

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!