[12:01] <mok01> Hi
[12:01] <persia> Hi.
[12:02] <persia> Anyone else here for the MOTU Meeting?
[12:02] <jpds> Afternoon.
[12:03]  * Hobbsee waves
[12:04] <persia> RIght.  Let's wait until we're 5, and get started.
[12:04] <mok01> Apparently there's something going on in classroom
[12:04] <persia> (more would be better, but less is boring)
[12:04] <persia> Yes, the "How to run a Bug Jam" session.
[12:04]  * james_w waves
[12:05] <persia> 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] <persia> OK.
[12:05] <persia> #startmeeting
[12:05] <MootBot> Meeting started at 06:05. The chair is persia.
[12:05] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[12:05] <persia> [link] https://wiki.ubuntu.com/MOTU/Meetings
[12:05] <MootBot> LINK received:  https://wiki.ubuntu.com/MOTU/Meetings
[12:06] <persia> [topic] Discussion about REVU
[12:06] <MootBot> New Topic:  Discussion about REVU
[12:06] <persia> mok01, You're up.
[12:06] <mok01> Well, I've written up a proposal for a revised workflow
[12:06] <mok01> https://wiki.ubuntu.com/REVUWorkflowProposal
[12:06] <persia> [LINK] https://wiki.ubuntu.com/REVUWorkflowProposal
[12:06] <MootBot> LINK received:  https://wiki.ubuntu.com/REVUWorkflowProposal
[12:07] <mok01> In principle it's not very different from what we have today
[12:07] <mok01> It's just organized so the flow is clearer to both uploaders and reviewer
[12:08] <mok01> and it gives us the possibility of closing for new packages
[12:08] <mok01> so we can focus on the ones that are already in the queue
[12:08] <persia> 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] <nhandler> mok01: I personally am against the idea of closing REVU for new packages
[12:08] <nhandler> persia: He had suggested after Feature Freeze iirc
[12:09] <mok01> That is one option, but I propose that it is up to the MOTUs to decide
[12:09] <persia> 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] <persia> In practice, of course, REVU is mostly completely ignored after FF, so perhaps it doesn't matter.
[12:10] <mok01> Yes, the problem is that the influx of new packages is greater than our capacity to process them
[12:10] <nhandler> 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] <nhandler> mok01: The same thing could be said about bugs on Launchpad. Should we stop accepting new bug reports?
[12:10] <mok01> nhandler: don't be silly
[12:10] <Hobbsee> nhandler: well, apport does get turned off for crashes in stable releases, for that very reason, fwiw.
[12:11] <mok01> Anyway, closing is a minor point.
[12:11] <nhandler> As for restructuring the lists, I am still a little unclear as to what this is meant to accomplish
[12:12] <mok01> According to the proposal, unreviewed uploads will be on it's own list
[12:12] <mok01> The packages that have received >= 1 review, move to the "In process" list
[12:13] <mok01> and then the progress pretty much like now
[12:13] <nhandler> 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] <nhandler> Currently, packages with 1 advocation are at the top and easy to see
[12:13] <nhandler> Packages that need work are at the bottom and out of the way
[12:13] <mok01> nhandler: ATM, the list is cluttered with completely new uploads and people putting the final touches on their package
[12:14] <nhandler> mok01: This is one reason more MOTUs should subscribe to packages
[12:14] <mok01> And cluttered by packages that already have an advocate, but the 2nd one has asked for some changes
[12:15] <mok01> nhandler: that's voluntary, of course
[12:16] <nhandler> mok01: It is, but subscribing to packages that you review would solve a LOT of the problems we currently have
[12:16] <Hobbsee> 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] <mok01> nhandler: I have reviewed a LOT this cycle, you don't need to explain to me how it works
[12:17] <nhandler> mok01: These comments are dirrected at you personally, they are just general comments
[12:17] <nhandler> Hobbsee: That is my understanding. But I don't think there is any official policy about it yet
[12:17] <mok01> nhandler: well, you prefixed your comments with my nick
[12:17] <Hobbsee> nhandler: because, if that's the case, this will not be such an issue next cycle.
[12:17] <persia> There's never been a policy about either way.
[12:18] <Hobbsee> 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] <mok01> 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] <persia> 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] <persia> The way to address this is to edit the wiki, not wait for some decision.
[12:19] <mok01> 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] <Hobbsee> mok01: Hurrah!  I agree that it should be discussed separately, but this discussion has that as a dependancy.
[12:20] <mok01> Hobbsee: well, not really. We can modify the workflow without such a decision
[12:20] <Hobbsee> score :)
[12:20] <mok01> IMO it will make reviewing life easier, and we can collectively focus on packages where the uploader is active
[12:21] <mok01> 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] <mok01> Of those 125, I estimate that about half have never receieved a review
[12:22] <mok01> So it would be good if they did not appear in the same list
[12:22] <mok01> Because then everybody would focus on the 60 or so, and they would get processed quicker
[12:23] <mok01> To more satisfaction for all
[12:23] <persia> Well, what's the goal?
[12:23] <persia> I always thought the goal was to get in the most interesting packages that were missing.
[12:23] <persia> Focusing on "active uploaders" doesn't seem to help this goal.
[12:23] <mok01> The goal is to get a process where we don't spread ourselves too thin on a very large number of uploads
[12:24] <persia> 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] <mok01> persia: my proposal does not rule that out
[12:25] <mok01> persia: see use case 4
[12:26] <persia> Hrm.  I see.
[12:26] <persia> 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] <persia> Maybe we could just list the category in the table, rather than having separate lists?
[12:27] <mok01> That's a matter of layout I guess.
[12:27] <mok01> I don't see the point of having a very long cluttered list though
[12:28] <persia> Well, if you're not specifying which should be examined, what part is the clutter?
[12:28] <DktrKranz> 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] <mok01> DktrKranz: exactly
[12:28] <DktrKranz> ... but are we sure we don't focus too much on "almost ready" packages, discarding "New" packages?
[12:29] <DktrKranz> that's my major issue with it
[12:29] <persia> I don't think the ones that have previously been advocated should be considered those that don't need much review.
[12:29] <mok01> There is not much point of having 125 packages waiting for processing
[12:29] <persia> I think those require the *most* detailed review, in case the previous reviewer missed something.
[12:30] <mok01> It's better to give the final review to a package to get it moving along the pipeline
[12:30] <DktrKranz> It depends on how much detailed first review was
[12:30] <DktrKranz> I try to have a deep review first
[12:30] <DktrKranz> just to make sure major issues come out soon
[12:30] <mok01> persia: that's why I have the "Advocate" section, with packages that have 1 advocate.
[12:31] <mok01> They stay in that section
[12:31] <mok01> and don't go back to Processing unless the advocate removes the vote
[12:31] <DktrKranz> 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] <mok01> DktrKranz: yes
[12:32] <persia> mok01, Would perhaps continuance of advocacy meet that need: so that if someone advocates, the advocacy persists for further uploads?
[12:32] <mok01> persia: yes
[12:32] <persia> My fear there is that a change might mean that I no longer wanted to grant advocacy.
[12:33] <mok01> persia: from the logic, that if you've advocated a package at a certain stage, it's ok to improve it
[12:33] <mok01> persia: then you could remomve your advocacy
[12:33] <persia> 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] <persia> 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] <mok01> persia: you still have that option
[12:34] <mok01> persia: you can leave a not to the next reviewer that you want to approve the final pacakge
[12:34] <DktrKranz> What about have the second reviewer to ask for a confirmation of the first ACK before uploading?
[12:34] <mok01> :-)
[12:34]  * mok01 propose that we take a look at the REVU list now
[12:34] <mok01> http://revu.ubuntuwire.com/
[12:34] <MootBot> LINK received:  http://revu.ubuntuwire.com/
[12:35] <persia> mok01, But then I still get poked, which I don't prefer :(
[12:35] <mok01> Then you have to trust your fellow MOTUs
[12:36] <mok01> Most of the packages at the top have never received a review.
[12:36] <mok01> They were uploaded in november
[12:37] <mok01> I have notes that tell me which packages I follow
[12:37] <mok01> so I go to the bottom of the list to see if any of those have come back
[12:38] <mok01> That is deceitful to the people at the top, who think they are next in line
[12:38] <DktrKranz> 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] <persia> 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] <DktrKranz> and probably will never be
[12:40] <mok01> A lot of people just give up and go away with a bad impression of MOTU
[12:40] <mok01> Look at the length of the needs-work list
[12:41] <DktrKranz> 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] <persia> 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] <mok01> mentors,debian.net = never processed unless you find a sponsor
[12:41] <persia> Anyway, part of the issue is the assumption that just uploading to REVU is a good way to learn.
[12:41] <DktrKranz> people could be discouraged about long time for a review, but there are several options to speed up things
[12:41] <persia> 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] <DktrKranz> such asking in #ubuntu-motu during REVU days
[12:42] <persia> That was less true in the past, but it certainly discourages me from REVUing things where I don't see the benefit.
[12:42] <mok01> DktrKranz: yes, I give priority to people in IRC
[12:42] <mok01> persia: you don't have to
[12:42] <persia> Personally, I'd rather keep REVU *hard*, because I think we don't do enough for the packages we already maintain.
[12:42] <DktrKranz> persia: good point. There are packages which are there just to say "hey, I've packed something!"
[12:43] <persia> And discourage people from putting things there unless they really have some need to get it in the distro.
[12:43] <mok01> Now, though, we have PPAs and that ought to be able to take the load off REVU
[12:43] <persia> Well, yes, but it's also taken some of the reviewers away.
[12:43] <mok01> persia: but that is part of another discussion
[12:44] <persia> 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] <DktrKranz> I don't remember what, but I noticed a package made with ch*ckinst@ll some times ago...
[12:44] <mok01> Although I have thoughts about how to choose packages for review, the proposal is ONLY about organizing the web page differently
[12:45] <persia> I guess I just don't see the benefit.
[12:45] <mok01> persia: it wont be any worse for you then
[12:45] <persia> Fair.
[12:46] <mok01> OK, so if we look at the top of the REVU page... the packages with the green icons
[12:46] <DktrKranz> 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] <mok01> 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] <DktrKranz> now, we just can't
[12:47] <nhandler> 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] <DktrKranz> nhandler: this would be handled better via "neutral vote", IMHO
[12:49] <DktrKranz> "I don't like this, but it's minor and I won't push you back just for a typo"
[12:50] <persia> It seems there's still an assumption of a FIFO queue.  Do we want that for some reason?
[12:50] <mok01> 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] <mok01> Sometimes the 2nd advocate asks for a package to be split.
[12:50] <mok01> but even so, the package is in pretty good shape
[12:51] <mok01> with copyright etc.
[12:51] <DktrKranz> mok01: about REVU code change, do changes you propose affect current view of REVU page? Can both variant co-exist?
[12:52] <DktrKranz> both variant = actual display of packages and new way
[12:52] <mok01> DktrKranz: uhm... well the web page is just a view of the data base, so I'd think so
[12:52] <DktrKranz> so, we can have two pages
[12:52] <DktrKranz> just to see if people like the idea
[12:53] <mok01> DktrKranz: Solomonic solution
[12:53] <DktrKranz> so, it's just a matter of bring things back to repair
[12:53] <nhandler> Didn't someone have a "testing" version of REVU when they were testing the new theme?
[12:53] <persia> I'd like that.  While I'm not seeing a benefit in the abstract, I might see one with the example.
[12:53] <persia> Doesn't even need to be done in REVU code or live, but just a layout sample.
[12:54] <persia> nhandler, There's a few of them that were set up.  Dunno of any that are publically available.
[12:54] <DktrKranz> if we can have a REVU server up for a while, we can test things and eventually push on main site
[12:54] <DktrKranz> I could ask a friend of mine to host the stuff
[12:54] <mok01> I am willing to help with the programming
[12:55] <DktrKranz> is it Python?
[12:55] <mok01> I know python & postgresql pretty well
[12:55] <DktrKranz> or... is it ! perl? :)
[12:55] <mok01> DktrKranz: yes
[12:55] <mok01> python, mod_python
[12:55] <DktrKranz> mok01: I can lend a hand too
[12:55]  * nhandler likes python
[12:55] <nhandler> s/python/perl/
[12:56] <persia> 5 minutes.
[12:56] <persia> So, please criticise this summary:
[12:56] <mok01> What I'd need to test, is a copy of the database
[12:56] <persia> 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] <persia> Is that correct?
[12:57] <mok01> yes
[12:57]  * DktrKranz agrees
[12:57] <Hobbsee> ++
[12:57] <persia> mok01, Do you need the live DB, or could you upload a few packages to a test server?
[12:57] <mok01> uhm
[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] <persia> s/unpackaged/unpacked/
[12:58] <mok01> I was thinking of having a database locally, so I could play with it
[12:58] <mok01> I don't need the packages
[12:58] <DktrKranz> What about having the main DB without files? Is it a problem for REVU?
[12:58] <persia> Oh, the structure is in the REVU code.
[12:58] <persia> DktrKranz, The links will all be broken.
[12:58] <james_w> 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] <mok01> The structure is mostly in the file called index.py
[12:58] <persia> So, let's finish this with the following actions:
[12:58] <persia> mok01, Will investigate the REVU code, and play with the DB
[12:59] <persia> DktrKranz, will investigate hosting options for a testing REVU server
[12:59] <mok01> +
[12:59] <DktrKranz> agreed
[12:59] <persia> nhandler, will coordinate the process, and bring the discussion back to MOTU when we're reached the next step.
[12:59] <persia> Did I miss anything?
[13:00] <mok01> sounds about right
[13:00] <persia> OK.  Any other business that needs to be raised for this meeting?
[13:00] <DktrKranz> I'm fine with that
[13:00] <mok01> (so who do we need to get in touch with to get a copy of the database?)
[13:01] <persia> mok01, nhandler (or I'll help if that breaks)
[13:01] <persia> Any volunteers to write the minutes and send them out?
[13:02] <mok01> I am not impartial, so it shouldn't be me ;-)
[13:02] <nhandler> persia: I don't have access to spooky yet
[13:02] <mok01> I have access, but not to the database
[13:02]  * DktrKranz raises his hand to write minutes
[13:02] <persia> DktrKranz, Thank you.
[13:02] <persia> #endmeeting
[13:02] <MootBot> Meeting finished at 07:02.
[13:02] <DktrKranz> not before tomorrow, though :(
[13:02] <mok01> Thanks everyone! I have to run, another meeting coming up!
[13:03] <DktrKranz> I have to move my office to a new location today
[13:04] <DktrKranz> 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] <pitti> hello
[14:58] <ScottK> o/
[14:59] <cjwatson> afternoon
[14:59] <zul> hello
[15:00] <rickspencer3> hello
[15:00] <Riddell> quick, let's release before we find problems
[15:00] <cjwatson> too late
[15:00] <slangasek> heh
[15:01] <slangasek> morning, folks
[15:02] <slangasek> pgraner, davidm, Riddell, sbeattie, Hobbsee: there?
[15:02] <zul> im subbing for dendrobates today
[15:02] <sbeattie> barely
[15:02] <Riddell> mm hmm
[15:02] <pgraner> slangasek: yep
[15:03] <slangasek> zul: ah, hello then :)
[15:03] <zul> hello
[15:04] <davidm> slangasek, hi
[15:05] <slangasek> ok, sounds like we've got everyone we're going to get, let's get started
[15:06] <slangasek> #startmeeting
[15:06] <MootBot> Meeting started at 09:06. The chair is slangasek.
[15:06] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:06] <slangasek> [TOPIC] Getting a head start on 8.04.3 point release
[15:06] <MootBot> New Topic:  Getting a head start on 8.04.3 point release
[15:08] <slangasek> 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] <slangasek> [LINK] https://bugs.launchpad.net/ubuntu/hardy/+bugs?field.milestone=2132 - targeted bugs for 8.04.3
[15:08] <MootBot> LINK received:  https://bugs.launchpad.net/ubuntu/hardy/+bugs?field.milestone=2132 - targeted bugs for 8.04.3
[15:09] <pitti> noted
[15:09] <cjwatson> ack
[15:10] <cjwatson> three for foundations I think, plus that base-installer one that TBH may not happen
[15:10] <slangasek> ok, on to team reports
[15:10] <slangasek> [TOPIC] QA team
[15:10] <MootBot> New Topic:  QA team
[15:10] <sbeattie> 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] <slangasek> sbeattie: anything you want to cover on this, since heno's not here?
[15:11] <sbeattie> not much, davmor2 is doing smoke testing, anything to say?
[15:11] <sbeattie> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/314263 has hit people filing apport bugs.
[15:12] <sbeattie> so it'd be nice to get that squashed asap.
[15:12] <pitti> Chris Coulson is debugging that ATM, and he found the reason
[15:12] <slangasek> sbeattie: noted; that one's on the hit list
[15:12] <pitti> not a solution yet, though (just told me 20 mins ago)
[15:13] <slangasek> [TOPIC] Desktop team
[15:13] <MootBot> New Topic:  Desktop team
[15:13] <sbeattie> okay, otherwise I don't have anything to say here, I just realized 5 min ago that heno was traveling.
[15:13] <slangasek> rickspencer3: hi
[15:13] <rickspencer3> hi
[15:13] <slangasek> sbeattie: ack, thanks
[15:14] <pitti> 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] <slangasek> 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] <pitti> For 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 upstream
[15:15] <cjwatson> the oem-config one on the desktop list may well be foundations
[15:15] <rickspencer3> I think that we are on top of them
[15:15] <cjwatson> I'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 again
[15:15] <MootBot> ACTION received:  chriscoulson to fix bug #314263 so GNOME URI passing works again
[15:15] <pitti> slangasek: I dont' think we actually need to discuss any of the bugs; it's mainly a status update
[15:15] <rickspencer3> and the status is covered on our wiki
[15:15] <rickspencer3> however, I would be happy to discuss if it seems useful
[15:15] <slangasek> [LINK] Desktop team summary at https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus
[15:15] <MootBot> LINK received:  Desktop team summary at https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus
[15:16] <cjwatson> pitti: 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] <slangasek> 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] <pitti> I can't say, TBH
[15:17] <pitti> I'll ask tseliot/bryce
[15:17] <slangasek> ArneGoetje: can you test bug #321311 with whatever the default CJK IMs are?
[15:17] <rickspencer3> slangasek: ack on the severity rating for 321311
[15:17] <lool> slangasek: I think I got this bug without GTK_IM* set, and others confirmed this as well
[15:18] <slangasek> 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] <rickspencer3> 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] <cjwatson> rickspencer3: deja vu all over again
[15:18] <pitti> tseliot works on the nvidia drivers right now
[15:18] <rickspencer3> as a contingency measure
[15:18] <cjwatson> slangasek: ok, that's good
[15:18] <pitti> so they might make it to alpha4
[15:18] <slangasek> [ACTION] slangasek to follow up with bryce regarding binary driver status
[15:18] <MootBot> ACTION received:  slangasek to follow up with bryce regarding binary driver status
[15:18] <pitti> apparently new upstream releases just went out
[15:18] <rickspencer3> 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] <slangasek> pitti: oh, nice
[15:19] <pitti> slangasek: so make that for ati
[15:19] <lool> https://bugs.launchpad.net/bugs/320666
[15:20] <slangasek> [ACTION] slangasek to follow up on bug #320666 to find out why users without GTK_IM_MODULE set are also affected
[15:20] <MootBot> ACTION received:  slangasek to follow up on bug #320666 to find out why users without GTK_IM_MODULE set are also affected
[15:22] <slangasek> nothing we need to discuss as far as the Desktop specs?
[15:22] <pitti> my biggest concern right now is landing the DX/OLS stuff
[15:22] <pitti> rickspencer3: you seem to be more up to date than me for that?
[15:22] <rickspencer3> yes
[15:22] <slangasek> right, I was just noticing that was the first item - should Julian have a standing invite to release meetings as well?
[15:23] <rickspencer3> they are packaging code drop #2 today, so should be available for us on Monday
[15:23] <rickspencer3> slangasek: I think dbarth might be more appropriate than julian
[15:23] <rickspencer3> though julian does own some deliverables such as art, etc... that you might want to be tracking
[15:24] <slangasek> [ACTION] robbiew to add dbarth to the list of standing invites for release meetings
[15:24] <MootBot> ACTION received:  robbiew to add dbarth to the list of standing invites for release meetings
[15:24] <slangasek> 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] <rickspencer3> 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] <robbiew> slangasek: done
[15:25] <slangasek> \o/
[15:25] <rickspencer3> I don't know how far they have gotten on the KDE parts, though
[15:25] <rickspencer3> 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] <slangasek> ok
[15:26] <rickspencer3> hth
[15:26] <slangasek> yes, thanks
[15:26] <slangasek> let's move on then
[15:26] <slangasek> davidm is on a call, so let's skip Mobile for now
[15:27] <slangasek> [TOPIC] Kernel team
[15:27] <MootBot> New Topic:  Kernel team
[15:27] <slangasek> pgraner: hi
[15:27] <pgraner> slangasek: hello
[15:27] <pgraner> slangasek: We are on track for all of the specs and other action items
[15:28] <pgraner> slangasek: our big deliverables are improved suspend and resume, ext4 integration, kernel crashdumps and kernel oops reporting...
[15:28] <pgraner> slangasek: as stated all are exactly where they should be for this point in the cycle
[15:29] <slangasek> 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] <slangasek> e.g., is bug #317781 getting investigation?
[15:29] <pgraner> 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] <pgraner> 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] <slangasek> 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] <ScottK> Is the libdrm header issue and the ports versioning problem on the list?
[15:31] <slangasek> pgraner: can you make sure that     *
[15:31] <slangasek>       https://bugs.launchpad.net/ubuntu/jaunty/+bugs
[15:31] <pgraner> 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] <slangasek> is also being tracked generally?
[15:31] <pgraner> ScottK: it is
[15:32] <ScottK> Great, because that's blocking a lot of stuff.
[15:32] <pgraner> 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] <slangasek> 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] <pgraner> slangasek: one would think
[15:33] <slangasek> pgraner: ok, I think we should discuss this further afterwards
[15:33] <slangasek> [ACTION] slangasek and pgraner to discuss kernel team milestoning/workflow
[15:33] <MootBot> ACTION received:  slangasek and pgraner to discuss kernel team milestoning/workflow
[15:33] <pgraner> slangasek: I'm trying to get it so that I know what will land when and if not people know aobut it
[15:34] <pgraner> slangasek: we can talk next week
[15:34] <slangasek> ok
[15:34] <pgraner> slangasek: your buying the beer :-)
[15:34] <slangasek> :-)
[15:35] <slangasek> one other action item for the coming week, that we discussed previously
[15:35] <slangasek> [ACTION] pgraner to provide a "kernel to userspace" communique describing relevant userspace-affecting changes for this cycle
[15:35] <MootBot> ACTION received:  pgraner to provide a "kernel to userspace" communique describing relevant userspace-affecting changes for this cycle
[15:35] <slangasek> delegate as needed, of course :)
[15:35] <pgraner> slangasek: of course :-)
[15:35] <slangasek> anything else to cover, or shall we move on?
[15:35] <pgraner> slangasek: I'm good
[15:36] <slangasek> [TOPIC] Mobile team
[15:36] <MootBot> New Topic:  Mobile team
[15:36] <slangasek> davidm: hi
[15:36] <davidm> hi
[15:36] <lool> hey, I'm still here actually
[15:36] <slangasek> lool: hi as well, if you have more to add
[15:36] <slangasek> :)
[15:36] <lool> (I thought I wouldn't make it)
[15:36] <davidm> Ah lool take it away
[15:36] <lool> So hmm I'll just repeat what I sent to slangasek via email; overview of what we work on for A4:
[15:37] <lool>  - general focus on armel and UNR
[15:37] <lool>  - target of getting at least an installable armel image, versatile
[15:37] <lool>  - lots of UNR churn lately as OEM sent some drops and filed a bunch of
[15:37] <lool>    bugs
[15:37] <lool> slangasek brought up https://bugs.launchpad.net/bugs/303232 which is on the radar already, but will be discussed at the sprint
[15:37] <lool> https://bugs.launchpad.net/bugs/299847 was new to me, and is actually board specific
[15:37] <lool> We woudl need the porter marvell board to diagnose further I'm afraid
[15:38] <cjwatson> we have rimu now
[15:38] <lool> We do? great
[15:38] <cjwatson> Adam brought it up last night
[15:38] <davidm> lool, porter up as of last night
[15:38] <lool> 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] <slangasek> lool: shall I give you an action to follow up on the marvell issue?
[15:39] <lool> The biggest risk for A4 from us is that we lack resources to test all flavours
[15:39] <lool> slangasek: If you think its still release critical sure; I had actually in mind to drop its severity
[15:40] <slangasek> [ACTION] lool to follow up on bug #299847 on rimu to assess its scope & severity
[15:40] <MootBot> ACTION received:  lool to follow up on bug #299847 on rimu to assess its scope & severity
[15:40] <lool> 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] <slangasek> lool: what are the set of flavors that are relevant for A4?
[15:40] <lool> MID, UNR, and armel/versatile/d-i are the ones we will test
[15:40] <lool> slangasek: Perhaps we should list some d-i armel images in the tracker
[15:40] <cjwatson> we'll need to get the last added to iso.qa
[15:40] <cjwatson> snap
[15:40] <lool> hehe
[15:40] <lool> I think that's all I ahd
[15:40] <lool> There's a kernel upload pending for us
[15:41] <slangasek> [ACTION] slangasek to ask armel/versatile/d-i to be added to ISO tracker
[15:41] <MootBot> ACTION received:  slangasek to ask armel/versatile/d-i to be added to ISO tracker
[15:41] <lool> cjwatson grabbed it already
[15:41] <cjwatson> s/pending/in the queue/
[15:41] <cjwatson> d-i needed a rebuild anyway, so I'll do that Monday at the latest
[15:41] <slangasek> lool: 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:42] <cjwatson> versatile is testable in qemu (I know you didn't ask, so you may already know this, but just for the record)
[15:42] <lool> slangasek: MID is easy to test
[15:42] <lool> slangasek: it can be tested in qemu
[15:42] <lool> lvm etc.
[15:42] <lool> *kvm
[15:42] <ogra> unr needs composite
[15:42] <lool> slangasek: UNR requires GL though
[15:43] <lool> So it might be something we could do with vbox in the future, but right now it requires hardware
[15:43] <slangasek> is there a test case description at least for MID on the ISO tracker?
[15:43] <lool> We will have at least one or two netbooks which we will probably use for testing
[15:43] <slangasek> and 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] <lool> I don't remember; MID is already in the tracker though
[15:44] <davidm> eee PC 700 -900 -1000 Acer Aspire One and Samsung NC10
[15:44] <davmor2> slangasek: I have an AAO to test on
[15:44] <slangasek> lool: 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 documentation
[15:44] <lool> slangasek: 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 flavours
[15:44] <davidm> That will be the hardware for UNR, PO issued for same
[15:44] <lool> slangasek: Ok; give us an action and I'll either document or delegate that  :-)
[15:44] <ogra> Q1U is fine for unr testing as well btw
[15:45] <slangasek> [ACTION] lool, davidm to provide MID test case documentation for the ISO tracker
[15:45] <MootBot> ACTION received:  lool, davidm to provide MID test case documentation for the ISO tracker
[15:45] <slangasek> anything else?
[15:45] <lool> Nope
[15:46] <lool> slangasek: err action to add armel to tracker
[15:46] <lool> Or I missed it
[15:46] <slangasek> I actioned myself for that
[15:46] <lool> ah no it's there, sorry
[15:46] <slangasek> [TOPIC] Foundations team
[15:46] <MootBot> New Topic:  Foundations team
[15:46] <cjwatson> ok, quick summary of bugs from the agenda:
[15:46] <cjwatson> 44194: 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 bug
[15:47] <cjwatson> 59695: I believe the remaining part (pm-utils) is slangasek's, and is reasonably well-understood
[15:47] <cjwatson> 272314: fixed
[15:47] <cjwatson> 309215: slangasek already targeted to alpha-6, which I think is reasonable
[15:47] <cjwatson> 311228: fix committed
[15:47] <cjwatson> 317068: I believe evand is well in progress on this one; worst case we'll fix it on Monday at the sprint
[15:47] <cjwatson> also, 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] <cjwatson> however, I did run into bug 303515 in the process
[15:47] <cjwatson> I'm somewhat concerned that that was previously triaged to Low importance and largely ignored
[15:48] <cjwatson> (it was on shadow up to now, I think it's actually pam though)
[15:48] <slangasek> I think that's a dupe of another bug that was already reported against pam
[15:48] <slangasek> which wasn't marked 'low', but takes a massive surgery on libpam to fix
[15:48] <cjwatson> I looked and couldn't fine it
[15:48] <cjwatson> find
[15:49] <cjwatson> oh, bug 198730?
[15:49] <slangasek> I don't think so
[15:49] <cjwatson> no, maybe not
[15:49] <slangasek> the problem is the PAM stack returning the wrong error code and passwd printing a confusing message
[15:50] <slangasek> we can discuss that after the meeting in more depth?
[15:50] <cjwatson> wrong error code, namely PAM_SUCCESS? :-)
[15:50] <slangasek> yes
[15:50] <cjwatson> happy to, it seems to be a regression versus Debian unless I miss my guess, I assume due to the new PAM configuration layout
[15:50] <slangasek> yes
[15:51] <slangasek> [ACTION] slangasek and cjwatson to discuss/brainstorm on bug #303515
[15:51] <MootBot> ACTION received:  slangasek and cjwatson to discuss/brainstorm on bug #303515
[15:51] <cjwatson> ok
[15:51] <slangasek> are there any other bugs that ought to be escalated for Foundations that we haven't yet?
[15:51] <cjwatson> I'm paying attention to qa-jaunty-foundations as well as a general rule
[15:52] <cjwatson> I don't *think* there are any that badly need escalation there, but will check
[15:52] <slangasek> ok
[15:52] <cjwatson> regarding specs, Robbie is more up-to-date than I am; we are behind on spec writing/review though, and trying to catch up
[15:52] <slangasek> 44194> fwiw, I was thinking to fix this by just moving the stuff to /lib and be done with it :)
[15:52] <cjwatson> yes, although that's hairy with regard to state directories
[15:52] <cjwatson> if /usr is separate, /var may well be too
[15:53] <slangasek> yes, I'm planning to finish all my spec drafting today... :)
[15:53] <robbiew> heh
[15:53] <cjwatson> I gathered, though, that the problem was not merely that /usr was unmounted, but also that filesystems were potentially not yet writable
[15:53]  * robbiew was just about to "remind" slangasek
[15:53] <cjwatson> but I only saw this bug for the first time today
[15:54] <slangasek> cjwatson: I think there are provisions for early write to /var with bind mount twiddling; we can diagnose further after the meeting tho
[15:54] <cjwatson> I'm running out of time in my day and lots to do still, so if "after the meeting" is "in Berlin", that's great
[15:54]  * slangasek nods
[15:55] <slangasek> robbiew: anything you want to add about individual specs, or should we move on?
[15:55] <robbiew> nope...move on
[15:55] <slangasek> [TOPIC] Server team
[15:55] <MootBot> New Topic:  Server team
[15:55] <slangasek> zul: hi
[15:55] <zul> hey
[15:55] <cjwatson> I'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 there
[15:55] <cjwatson> (sorry, didn't mean to overflow our slot, lag)
[15:55] <slangasek> noted
[15:56] <zul> nothing to really report on our side we continue to reduce the size of the seeds so that the cloud computing stuff can fit on there
[15:57] <slangasek> zul: 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 it
[15:57] <zul> checking
[15:57] <slangasek> bug #305264 needs a judgement call from the server team (either generally, or from the security guys)
[15:58] <zul> ok ill nudge the security team to look at it, and ill upload the nmap one today
[15:58] <slangasek> ok, great
[15:59] <slangasek> anything else you want to cover, or shall we keep going so we can get out of here early? :)
[15:59] <zul> keep on going :)
[15:59] <slangasek> [TOPIC] MOTU
[15:59] <MootBot> New Topic:  MOTU
[15:59] <slangasek> ScottK: hi
[15:59] <ScottK> Hello
[15:59] <ScottK> A couple of areas worth mentioning here I think.
[16:00] <ScottK> There 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] <ScottK> I think we are a long way from consensus on it and I would really hope we avoid premature uploads.
[16:01]  * slangasek nods
[16:01] <ScottK> The only other significant issue is we got pushed into a ghc6 transition by accident.
[16:01] <slangasek> hmm, was the 'accident' before or after the round of ghc6 sync requests?
[16:01] <ScottK> Someone didn't understand how those packages relate to each other and so they are going to have to be rebuilt.
[16:01] <ScottK> It was before, I'm pretty sure.
[16:02] <ScottK> It's in progress now.
[16:02] <slangasek> ok
[16:02] <ScottK> I doubt it'll be done by feature freeze, but I don't think it'll be an issue in the end.
[16:02] <cjwatson> the accident was before
[16:02] <slangasek> ScottK: something we should revisit the status on next meeting?
[16:03] <cjwatson> I had thought those sync requests cleaned up most of it, actually
[16:03] <ScottK> We'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] <ScottK> motu-release
[16:03] <slangasek> MOTU release?
[16:03] <slangasek> ok
[16:03] <ScottK> Initial for this cycle.
[16:03] <ScottK> We'll have 3 returning and one or two new people.
[16:04] <ScottK> I'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 transition
[16:04] <MootBot> ACTION received:  ScottK to report back on the status of ghc6 transition
[16:04] <ScottK> That's all I have unless anyone else has something.
[16:04] <slangasek> good to hear that motu-release is still healthy, both with ongoing committments and new blood :)
[16:05] <slangasek> thanks for the report
[16:05] <slangasek> [TOPIC] General feature update
[16:05] <MootBot> New Topic:  General feature update
[16:05] <slangasek> everything here /should/ already be covered by the per-team reports, but if this jogs anyone's memory...
[16:06] <ScottK> We landed KDE 4.2.0 in Kubuntu Jaunty on release day.
[16:06] <pitti> congrats!
[16:06] <ScottK> That didn't get mentioned so far...
[16:06] <rickspencer3> yeah!
[16:06] <pitti> what's the response so far?
[16:06] <slangasek> yay :)
[16:06] <ScottK> Very positive.
[16:06] <pitti> a big "ooooh, so much better than 4.1!!!1!"?
[16:07] <ScottK> Yeah.
[16:07] <Riddell> planet gnome was impressed :)
[16:07] <ScottK> More like "This is the KDE4 I've been waiting for"
[16:07] <rickspencer3> great news
[16:07] <slangasek> ScottK: oh, on the subject of Kubuntu, is bug #289907 on the radar of anyone who has upload rights?
[16:07] <cjwatson> several installer bits and pieces (oem-config-server, server-pre-installation) likely to be landing piecemeal over the next couple of weeks
[16:07] <ScottK> We've also got Intrepid packages in a PPA to get wider exposure.
[16:08] <cjwatson> manual package selection in the server installer is a big one there, assuming that I actually manage to get it working
[16:08]  * ScottK looks at Riddell for the qt4 bug?
[16:08] <Riddell> I can take a look at that
[16:09] <slangasek> [ACTION] Riddell to follow up on bug #289907
[16:09] <MootBot> ACTION received:  Riddell to follow up on bug #289907
[16:09] <slangasek> [TOPIC] Known regressions
[16:09] <MootBot> New Topic:  Known regressions
[16:09] <slangasek> [LINK] https://bugs.launchpad.net/ubuntu/+bugs?field.tag=regression-potential
[16:09] <MootBot> LINK received:  https://bugs.launchpad.net/ubuntu/+bugs?field.tag=regression-potential
[16:09] <slangasek> [LINK] http://www.ubuntu.com/testing/jaunty/alpha3#Known%20issues
[16:09] <MootBot> LINK received:  http://www.ubuntu.com/testing/jaunty/alpha3#Known%20issues
[16:10] <cjwatson> the IPv6 one is something I've been trying to puzzle out
[16:10] <cjwatson> bug 313218
[16:10] <slangasek> I 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 them
[16:11] <cjwatson> I am not convinced that 313218 is a kernel bug, since glibc is supposed to deal with this situation
[16:11] <slangasek> (a bunch of the bugs on there need to be retagged as regression-release now for 8.10...)
[16:11] <slangasek> fyi, 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 stragglers
[16:12] <sbeattie> slangasek: I'll do the retagging
[16:12] <slangasek> cjwatson: 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 intrepid
[16:12] <MootBot> ACTION received:  sbeattie to clean up regression-proposed tags on bugs present in intrepid
[16:13] <cjwatson> yeah, why not
[16:13] <slangasek> [ACTION] cjwatson to follow up on bug #313218
[16:13] <MootBot> ACTION received:  cjwatson to follow up on bug #313218
[16:13] <ScottK> One 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:14]  * pitti sobs
[16:14]  * rickspencer3 pats pitti's shoulder
[16:14] <slangasek> ah, congrats to server team and the kubuntu folks there
[16:14] <pitti> "minimize desktop footprint" is such an euphemism here... :-(
[16:14]  * ScottK hands pitti a tissue.
[16:14] <slangasek> heh
[16:15] <slangasek> [TOPIC] Hardware testing
[16:15] <MootBot> New Topic:  Hardware testing
[16:15] <slangasek> including here for completeness, but I don't think there's anything to report yet
[16:15] <slangasek> (nor do we have heno here to do the reporting)
[16:15] <cjwatson> pitti: gconf/gettext, right? :-)
[16:15] <slangasek> [TOPIC] ISO size
[16:15] <MootBot> New Topic:  ISO size
[16:16] <pitti> cjwatson: already told slangasek about that gem :)
[16:16] <slangasek> I'm gratified to see that the latest OOo upload did *not* push Ubuntu CDs oversize :-)
[16:16] <slangasek> unfortunately, we've managed to push the *DVD* oversized at some point!
[16:16] <pitti> I'm also in conversation with Celso about shipping the NGOME help in langpacks
[16:16] <slangasek> so if anyone knows of things that should just plain be tossed out of main... nominate them loudly :)
[16:16] <pitti> if we are very lucky, the new custom upload format for that can be implemented quickly in Soyuz
[16:17] <pitti> but I wouldn't hold my breath for that for Jaunty
[16:17] <slangasek> [AOB]
[16:17] <slangasek> anything else we've missed?
[16:18] <slangasek> assuming there'll be plenty of other opportunities still for one-on-one conversations :)
[16:18] <slangasek> #endmeeting
[16:18] <MootBot> Meeting finished at 10:18.
[16:18] <slangasek> thanks, all!
[16:18] <pitti> thanks everyone
[16:20] <rickspencer3> bye