[12:01] <persia> cody-somerville, soren, cjwatson, geser, stgraber, bdrung: about?
[12:02] <soren> yeah
[12:04] <cjwatson> hi
[12:04] <cjwatson> don't we have a new board yet? :)
[12:05] <persia> We're picking one today, so this is the last for both of you.
[12:05] <persia> If we fail to get quorum to pick one, I'll pass the information received to the TB, and so there will be one for next time.
[12:09] <persia> stgraber, cody-somerville, bdrung ?
[12:09] <persia> Just need one more.
[12:13] <cjwatson> sigh
[12:14] <persia> Right.  I don't want to chair a non-meeting.
[12:14] <persia> cjwatson, soren: Thanks a lot for serving on the DMB.  You will be missed.
[12:14] <persia> I'll ask the TB to select a new DMB from the nominees, with the poll data.
[12:14] <persia> And the new DMB can process the pending applications.
[12:15] <cjwatson> You're welcome; bye!
[12:15] <cjwatson> oh wait
[12:15]  * geser waves
[12:15] <persia> Oh, hey geser!
[12:15] <cjwatson> aha, quorum
[12:15] <persia> #startmeeting
[12:15] <MootBot> Meeting started at 06:15. The chair is persia.
[12:15] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[12:16] <persia> [LINK] https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda
[12:16] <MootBot> LINK received:  https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda
[12:16] <persia> [TOPIC] Selection of a new DMB
[12:16] <MootBot> New Topic:  Selection of a new DMB
[12:16]  * persia ends the poll
[12:16]  * Amaranth rushes to vo....oh
[12:16] <Amaranth> ;)
[12:17] <persia> So, we had some nominees, and we had a poll.
[12:17] <persia> Results are now available, with 93 voters.
[12:17] <persia> [LINK] http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_924ef5b8e9f6d03b
[12:17] <geser> not bad
[12:17] <MootBot> LINK received:  http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_924ef5b8e9f6d03b
[12:18] <persia> So, do we wish to accept the winning set from CIVS?  Any reservations or concerns?
[12:18]  * bdrung is here now.
[12:18] <soren> persia: lgtm
[12:18] <cjwatson> so all incumbents stay, and Laney and maco replace soren and me
[12:19] <persia> That would be the result, yes.
[12:19] <cjwatson> fairly tight race around the boundary
[12:19]  * cdbs came last
[12:20] <cjwatson> but I don't see a reason to be concerned about the result
[12:20] <persia> Well, if both of those departing are happy, and since the rest of us have obvious bias, I'll call that agreed.
[12:21] <persia> [AGREED} New DMB to be the winners of the CIVS poll, without modification or adjustment.
[12:21] <MootBot> AGREED received: [AGREED} New DMB to be the winners of the CIVS poll, without modification or adjustment.
[12:21] <Daviey> "None of the above" did particularly poorly.
[12:21] <cjwatson> does that come into effect after this meeting, or immediately? :)
[12:21] <cjwatson> (because if immediately, we probably just became inquorate)
[12:21] <persia> We'd lose quorum if it's immediate.  You're the closest to the TB we have available: how long did the term extension last?
[12:22] <cjwatson> "does not expect this to be complete until after 14th February", from your original mail
[12:22] <cjwatson> and the TB agreed to an extension covering that
[12:23] <cjwatson> so I think it's OK to consider the extension as covering this meeting
[12:23] <persia> I assert it's still 14th February, as none of us are in New Zealand or points east.
[12:23] <persia> Moving on.
[12:23] <cjwatson> the new DMB will need to select their own meeting times, etc., anyway
[12:23] <persia> [TOPIC] MOTU Application for Sylvestre Ledru
[12:23] <MootBot> New Topic:  MOTU Application for Sylvestre Ledru
[12:24] <persia> [LINK] https://wiki.ubuntu.com/UbuntuDevelopment/SylvestreLedruMOTU
[12:24] <MootBot> LINK received:  https://wiki.ubuntu.com/UbuntuDevelopment/SylvestreLedruMOTU
[12:24] <persia> The LP link on that page is broken.
[12:24] <persia> [LINK] https://launchpad.net/~sylvestre
[12:24] <MootBot> LINK received:  https://launchpad.net/~sylvestre
[12:24] <cdbs> Why was the page created under the UbuntuDevelopment/ directory?
[12:24] <cdbs> is there a change in policy?
[12:24] <cjwatson> no
[12:24] <persia> No
[12:25] <cjwatson> wiki layout in "random" shocker :)
[12:25] <bdrung> the launchpad link is broken
[12:25] <persia> bdrung, That's why I posted two links :)
[12:25] <persia> Sylvestre, are you present?
[12:25] <cjwatson> I've taken the liberty of editing his application to fix the LP link
[12:28] <persia> He doesn't seem to be present.
[12:28] <persia> Moving on.
[12:28] <persia> [TOPIC] Development application for Dave Walker
[12:28] <MootBot> New Topic:  Development application for Dave Walker
[12:28] <Daviey> o/
[12:29] <persia> Daviey is applying for all of MOTU, Server, and Core at the same time.  I trimmed that down to just core-dev.
[12:29] <Daviey> persia, Yes, but i did want to go through the process for the other two
[12:29] <persia> Daviey's application has not yet aged the week we request.  Do we wish to review it today, or wait for general comments, and review next time?
[12:29] <cjwatson> core-dev covers the lot, although it's rational to apply for the lot since that means that if we decline his core-dev application he doesn't need to go through another application cycle for the others
[12:29] <persia> Daviey, code-dev is a member of both others.
[12:30] <persia> Indeed.  That's how I read it: if we reject core-dev, we re-review MOTU and Server.
[12:30] <Daviey> persia, Direct inclusion or through inheritance?
[12:30] <persia> inheritence.
[12:31] <persia> But, in practice, it doesn't matter.  You get the badges on LP.  You get accepted by the teams if you're working with them, etc.
[12:31] <Daviey> persia, yeah, it's just that server-dev is looking  kinda neglected.. so wanted to help raise the membership count addionally.
[12:31] <soren> Well, not he server package set one.
[12:31] <soren> s/ he/ the/
[12:32] <soren> core-dev isn't a member of that team, IIRC.
[12:32] <Daviey> the package set isn;t quite ready yet, is it cjwatson ?
[12:32] <soren> Or am I on crack again?
[12:32] <Daviey> I was under the impression  it was waiting for the first member for the process to be completed
[12:32] <soren> Yeah, core-dev is not a member of that team.
[12:33] <cjwatson> the package set exists and AFAIK is administered by the DMB
[12:33] <persia> No, the process is complete.  At this point, any issues are implementation bugs.
[12:33] <Daviey> Last time i polled the ACL, server-dev didn't have access.
[12:33] <cjwatson> indeed, that would imply the DMB delegating permissions
[12:34] <cjwatson> which is generally a separate discussion from creating a package set
[12:34] <cjwatson> oh, wait, the DMB owns ubuntu-server-dev
[12:34] <persia> And I believe we had that discussion at the time server-dev was created, and decided that we would not delegate at this time.
[12:34]  * Daviey wonders if he can be heard this meeting, but with the final ack being done with now+1 week pending criticism of his application.
[12:34] <cjwatson> == All uploaders for package set 'ubuntu-server' in 'natty' ==
[12:34] <cjwatson> Archive Upload Rights for ubuntu-core-dev: archive 'primary', package set 'ubuntu-server' in natty
[12:34] <cjwatson> Archive Upload Rights for ubuntu-server-dev: archive 'primary', package set 'ubuntu-server' in natty
[12:35] <cjwatson> so ubuntu-server-dev does have access to the ubuntu-server package set
[12:35] <persia> So all is good.
[12:35] <cjwatson> and mathiaz was the first member there
[12:35] <Daviey> oh... that has been updated since i  last polled then :/
[12:36] <Daviey> or i am on soren;s crack
[12:36] <persia> Opinions on questioning Daviey today?  Do any DMB members want more time to develop interesting questions?
[12:37] <soren> I have perhaps one question.
[12:37] <soren> Is there anything specific that you intend to work on that's outside of MOTU+ubuntu-server-dev's reach?
[12:38] <Daviey> soren, yes - I have an interest in the whole platform
[12:38] <Daviey> Which was one reason i worked on dpkg.
[12:38]  * soren can relate to that :)
[12:38]  * bdrung is still reading the application.
[12:38] <Daviey> The server set isn't exactly complete for my interests.
[12:39] <soren> ...but if we're not going the process the applicatino today, it doesn't matter anyway.
[12:39] <Daviey> You can see the difference if you look at the assigned packages for bug purposes and the package set
[12:39] <Daviey> it's reasonably large.
[12:39] <persia> cjwatson, geser: are you fine with questioning Daviey today?
[12:39] <geser> I'm fine
[12:40] <cjwatson> I'm OK, though I've added a brief endorsement on his application too so don't really have any questions
[12:40] <Daviey> One of the reasons i've got around to apply, is that i'm finding that I want to work on less - as i'm using up my favours of sponsorship working on things i HAVE to work on, rather than the addition of things i want to work on.
[12:40] <Daviey> s/apply/applying/
[12:41] <persia> Daviey, How do you think we can encourage more peer-review by Ubuntu Developers?
[12:41] <Daviey> persia, well the patch pilot scheme has IMO already made a massive difference to this.
[12:42] <Daviey> But it still lacks personal attachment.
[12:42] <soren> People use the patch pilot for peer reviews?
[12:42] <Daviey> No.
[12:42] <Daviey> Ah sorry
[12:42] <soren> Oh.
[12:42] <Daviey> i missread the question
[12:42] <persia> Does it?  While I like what patch-pilot is doing for sponsoring, I don't see how it helps peer-review between Ubuntu Developers.
[12:42] <Daviey> I think UDD can make a larger difference with this.
[12:43] <Daviey> I don't feel enough people use merge requests.
[12:43] <cjwatson> what do you mean by peer review?
[12:43] <Daviey> I agree that JFDI attitude can help productivity
[12:43] <cjwatson> you mean people who are already Ubuntu developers?  (just clarifying)
[12:43] <Daviey> cjwatson, Developers that can upload, asking peers to review it before uploading
[12:44] <cjwatson> ah, right, thanks
[12:44] <cjwatson> if you understood the question I suppose that's all that matters :)
[12:44] <Daviey> heh
[12:44] <Daviey> Yes, well JFDI can aid productivity - but something i have noticed; tradionally the server has often got a little rough end of the deal, when a feature in Desktop is needed
[12:45] <Daviey> Plymouth introduction was quite bad for Server IMO.
[12:45] <persia> Do you think encouraging peer review would help that, or do you think we need more coordination between flavours?
[12:45] <Daviey> And some packages where silly mistakes have been made, could have been avoided if they had a once over.
[12:46] <soren> Plymouth will end up as a big advantage for server users, too, though.
[12:46] <Daviey> Some packages i've seen have had almost hacking away at a bug, until it's fixed.
[12:46] <soren> ...but that's a separate discussion :)
[12:46]  * persia has seen packages hacked away at until they aren't fixed, but the tests passed
[12:46] <Daviey> persia, Yeah, i realised as i was typing that; it's two issues really.
[12:46] <cjwatson> one thing I noticed, as somebody caught in the middle, was that a number of server folks basically had the attitude of "no, it was fine as it was, we want you to rip this all back out" rather than an attitude of trying to improve new packages so that they could cover both server and desktop bases
[12:46] <Daviey> soren, agreed... but the introduction could have been better handled perhaps.
[12:46] <persia> So, what's your proposal?  Since you don't like it, and you're wanting to join Core dev...
[12:46] <cjwatson> do you think this is a fair criticism, is it recognisable to you, and what do you think we can do about it?
[12:47] <cjwatson> (this is very much something core-devs need to deal with - we're supposed to be integrating, not just picking a side)
[12:47] <Daviey> cjwatson, interesting... i had not seen that attitude being too obvious.
[12:47] <Daviey> cjwatson, I know some *users* mentioned that...but not sure it was clear cut within the team
[12:48] <cjwatson> ok, that's a reasonable response, the boundary wasn't always clear to me
[12:48] <Daviey> Many of the server team want to see more polish... and on a non-LTS release perhaps making it better is greater than stability on server.
[12:48] <Daviey> (not desktop or other flavours)
[12:49] <soren> I cannot count how many hours I've spent on IRC, IRL, on blogs, eetc explaining that event driven boot isn't *just* about speeding things up.
[12:49] <Daviey> soren, yes, upstart actually has more benefits to server than desktop IMO.
[12:50] <Daviey> Particulary if upstart adds some of the features it initially blueprinted.
[12:50] <soren> I can kind of see where people are coming from, though. Stuf that used to work suddenly didn't. It's easy to blame The New, Big Thing[tm].
[12:50] <Daviey> such as xinetd incorporation.
[12:51] <persia> So, let's step away from discussing upstart features.
[12:51] <Daviey> It's unfortunate that this often means increasing the delta with Debian.
[12:51] <persia> I'm still curious how the issue that makes Daviey unhappy could be addressed.
[12:52] <Daviey> persia, Something we considered at a team level was peer review of every upload after a certain mark in the release schedule
[12:52] <Daviey> It wasn't entirely agreed... but there was also some support for this.
[12:52] <Daviey> This was also discussed at the last UDS...
[12:52] <persia> Daviey, Did you imagine people would have reviews by people in their immediate teams (with interest in the package), or from other teams?
[12:53] <Daviey> ... and that was "eventful"... but that was the whole platform, not just a specific area.
[12:53] <Daviey> persia, both...
[12:53] <persia> Will you be bringing this issue to next UDS?
[12:53] <Daviey> If the package is depends/recommends of another team, then the merge proposal is a good way of notifing them of a potential diff
[12:53] <Daviey> persia, Yes.
[12:54] <geser> Daviey: isn't this peer-review like a spsonsorship for each upload which seems to slow you down in your productivitiy?
[12:54] <Daviey> geser, interesting you say that...
[12:54] <soren> :)
[12:54] <Daviey> I would like to point out the peer review blog post regarding either bzr/lp... don't have it handy
[12:55] <Daviey> But i think it might slow people down initially... but a review can be quite fast when in the habbit
[12:55] <bdrung> Daviey: how can we encourage devs to review packages from other teams? i am doing reviews for the package in the teams i am involved with and doing sponsoring, but i never reviewed packages from outside the team IIRC.
[12:55] <Daviey> geser, equally, sometimes it's good to be slowed down :)
[12:55] <Daviey> bdrung, It depends - is this packages outside a set?
[12:56] <persia> Not all team-maintained packages happen to have corresponding packagesets today.
[12:56] <bdrung> Daviey: i maintain most packages in Debian
[12:56] <persia> But for several teams, there are no outside contributions, despite the lack of packageset
[12:56] <Daviey> bdrung, you must be busy :)
[12:57] <Daviey> persia, The blog post i'd like to refer you to made specifc references to working outside your comfort zone.
[12:57] <Daviey> I'd LOVE to be more involved in development outside my daily duties
[12:57] <Daviey> I think it adds an education factor, and better understanding
[12:57] <persia> Hrm?  I'm just responding to the question "is this packages outside a set", to indicate that we have a very weak mapping of teams and packagesets currently.
[12:58] <Daviey> Sometimes doing reviews can be harder than doing the change yourself.. and reviewing outside comfort zone makes everyone better IMO.
[12:58] <Daviey> persia, Perhaps my response would have been better targeted towards bdrung
[12:59]  * persia is done with questions
[12:59] <Daviey> persia, but yes, having good defintions of teams/people linked to packages makes it easier to know who to talk to
[12:59] <Daviey> It then reduces the need to maintain in-head knowledge
[13:00] <Daviey> For example, i know not to touch some packages without speaking to certain individuals/teams
[13:00] <Daviey> And having a good person+team/package list defintion helps new contributors IMO.
[13:01] <bdrung> Daviey: assuming that i want to have my changes reviewed. then i push the bzr branch with my changes and create a merge proposal. wo will get notified with this merge proposal? what do i need to do to get notified about the packages i care about?
[13:02] <Daviey> bdrung, It might require a bug against LP, AIUI currently you have to select who reviews it.
[13:03] <Daviey> I want to add, that i don't think it should be mandatory, but a better ethos of people asking each other,.... perhaps even informal
[13:04] <bdrung> hm, it would be nice if lp gives you the possibility to subscribe to merge proposals for specific packages and a way to query who is subscribed and has upload rights (= similar to Uploaders in d/control)
[13:04] <Daviey> What i have said so far, is possibly better continued in a shared UDS session.... and not one chappy spouting his opinions :)
[13:04] <Daviey> bdrung, agreed!
[13:05] <bdrung> Daviey: yes, let's continue this discussion on an other channel / next UDS
[13:05] <persia> Daviey, The key is that this is a time when you have the spotlight to complain, and we have a duty to ensure you can move forward to solve the problem.  You taking it to UDS is the right answer in both cases.
[13:05] <persia> Anyone else have other questions for Daviey?
[13:06] <bdrung> no
[13:06] <soren> no
[13:06] <cjwatson> not I
[13:06] <persia> Great.
[13:07] <persia> Please feel free to vote by email to the d-m-b list, and I'll take a final tally when the comment period completes, with a renewed call for votes in the event that quorum is not reached.
[13:07] <persia> [TOPIC] Next Meeting
[13:07] <MootBot> New Topic:  Next Meeting
[13:07] <cjwatson> why vote by e-mail rather than here?
[13:07] <Daviey> Oh, and one more thing... i am *sometimes* wrong.  Greater peer review just might not work.. but it'sworth trying - if it doeshelp improve quality.
[13:08] <persia> I don't want to vote until after the comment period, in case something happens to change my vote.
[13:08] <cjwatson> in that case I shouldn't vote at all
[13:08] <persia> Probably not: we'll consider your comment.
[13:08] <Daviey> ho hum ding.
[13:09]  * cjwatson sends mail
[13:09] <persia> So, the newly selected DMB does not have agreement on meeting times.  We'll try to select some by email, and try to announce them by next Monday, to ensure that applicants can know when they have to attend a meeting when applying.
[13:09] <persia> [TOPIC] Anything else
[13:09] <MootBot> New Topic:  Anything else
[13:09] <persia> Anyone have anything here?
[13:11] <persia> Excellent.
[13:11] <persia> #endmeeting
[13:11] <MootBot> Meeting finished at 07:11.
[13:11] <soren> \o/
[13:11] <persia> Thanks everyone for coming.
[13:11] <cjwatson> So long and thanks for all the fish!
[13:11] <bdrung> :)
[13:12] <Daviey> thanks all for hearing me.
[13:17] <cjwatson> persia: oh, somebody should take over developer-membership-board@ and devel-permissions@ list administration from me.  Do you want to do it?
[13:18] <persia> Oh, very much not, but I suppose I ought.  Please do adjust them to me.
[13:18] <cjwatson> or if somebody else wants it that's fine too
[13:18] <cjwatson> do you have the passwords?
[13:18] <persia> And I'll hope I can find another victim from the new DMB.
[13:18] <persia> I don't believe I have the passwords: I'd appreciate them fresh in any case.
[13:19] <cjwatson> I'll send you them by encrypted mail
[13:20] <persia> Thanks.
[13:20] <persia> How would you like us to make requests for TB-changes to ACLs?  random ping?  mail to you?  Mail to TB?
[13:21] <cjwatson> mail to TB is probably the right thing
[13:21] <cjwatson> I'm sure I'll often pick them up, but it would be best not to enshrine myself in a process
[13:25] <persia> makes sense.  I'll ensure we do that in the future.
 hm, it would be nice if lp gives you the possibility to subscribe to merge proposals for specific packages and a way to query who is subscribed and has upload rights (= similar to Uploaders in d/control)  <-- yes yes yes please
[15:58] <skaet> hi ara, bjf
[15:58] <bjf> moin
[15:58] <ara> hey skaet!
[15:59]  * charlie-tca waves
[15:59]  * skaet waves back to charlie-tca 
[15:59]  * hggdh grabs new coffee
[15:59] <jibel> Hi all!
[16:00]  * marjo waves
[16:00] <skaet> looks like quorum,  so time to start.  :)
[16:01] <skaet> #startmeeting
[16:01] <MootBot> Meeting started at 10:01. The chair is skaet.
[16:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:01] <skaet> Reminder, please follow the convention  of using ".." on a separate line when you've finished typing.    Also, If someone wants to comment on the last point, please "o/", so we know to wait.
[16:01] <skaet> This meeting will be focusing on the 10.04.2 release.
[16:01]  * charlie-tca hides
[16:01] <skaet> Couple of snags cropped up in the image creation on Friday, and a few more on the sniff testing over the weekend, so want to make sure we're all seeing the same priorities
[16:02] <ara> sounds like a plan
[16:02]  * zul waves
[16:02] <skaet> On the good news front,  hardware cert has mostly finished the 2 week hardware certification runs, and no regressions were found as of last friday.  More details from ara later. :)
[16:03] <skaet> Images currently under rebuild are Xubuntu, and the K/Ubuntu DVDs.
[16:03] <skaet> Any questions before I get into the mailed out agenda/round table?
[16:03] <skaet> ..
[16:03] <ara> skaet, are we building Xubuntu 10.04.2 images? :)
[16:03] <skaet> ara, yes they're being rebuilt.
[16:04] <ara> I thought point releases images were just for Ubuntu
[16:04] <ara> I guess I was wrong
[16:04] <charlie-tca> \o
[16:04] <skaet> charlie-tca, go
[16:04] <charlie-tca> There are being built by request, for Xubuntu
[16:05] <charlie-tca> We did not do the .1 release, and wanted to get new stuff into the image, instead of the 352 updates after installing
[16:05] <charlie-tca> ..
[16:05] <marjo> charlie-tca: are testers lined up & committed?
[16:05] <charlie-tca> yes
[16:06] <marjo> charlie-tca: thx much
[16:06] <charlie-tca> You are welcome
[16:06] <skaet> ara, marjo - They are also being built for kubuntu.
[16:06] <marjo> skaet: ack
[16:06] <skaet> ok, no more hands, so on to the round table
[16:07] <skaet> [TOPIC] HW cert results and final image tests planned - ara
[16:07] <MootBot> New Topic:  HW cert results and final image tests planned - ara
[16:07] <ara> The HW testing for 10.04.2 went pretty well. We are happy with the coverage we got. The results are available at:
[16:07] <ara> [LINK] http://people.canonical.com/~hwcert/point-release-testing/10_04_2.html
[16:07] <MootBot> LINK received:  http://people.canonical.com/~hwcert/point-release-testing/10_04_2.html
[16:07] <ara> The systems that didn't get tested are due to problems of infrastructure or faulty hardware that needs to get replaced, but all in all, I think the results are good enough to give the thumbs up hardware wise.
[16:07] <skaet> :)
[16:08] <ara> About the testing of the final images, has anything hardware related changed from the candidate images until now?
[16:08] <skaet> bjf, sconklin: ^^ ?
[16:09] <sconklin> Not sure why you called on me, we don't have anything to do with the testing . . .
[16:09] <skaet> sconklin - has any change gone in in the last 2 weeks that could impact the hardware that you're aware of?
[16:09]  * skaet thinks not, but is just double checking.
[16:09] <sconklin> no.
[16:10] <bjf> you've not taken a new kernel from us during the point release process, so how could it ?
[16:10] <skaet> bjf, fair enough
[16:11] <ara> skaet, then, I guess there is no need to test the final images in hardware
[16:12] <ara> skaet, ?
[16:12] <skaet> ara,  sorry,  thinking if the boot infrastruture has changed
[16:13] <skaet> lets assume not unless rest of meeting brings up a good reason then.
[16:13] <ara> skaet, OK, so that's all from me
[16:13] <ara> ..
[16:13] <skaet> [TOPIC] QA sniff testing from weekend and hot issues - jibel
[16:13] <MootBot> New Topic:  QA sniff testing from weekend and hot issues - jibel
[16:14] <jibel> 10.04.2 ISO Testing started last weekend and is going well.
[16:14] <jibel> 2 major issues have been found:
[16:14] <jibel>  * bug 718749 (rebuild in progress)
[16:14] <jibel>  * bug 645818 (not a bug in lucid)
[16:14] <jibel> For 645818, we are looking for someone with a Lucid system, to create a bootable usb and confirm that he's not affected by this issue.
[16:14] <jibel> Last week, we have tested the upgrades from K/Ubuntu Desktop i386/amd64 Hardy and Karmic to 10.04.2.
[16:15] <jibel> 2 have been found issues found:
[16:15] <jibel> * bug 715206
[16:15] <jibel> * bug 715247
[16:15] <jibel> Untested images:
[16:15] <jibel> * Ubuntu Server Installation and upgrade
[16:15] <jibel> ..
[16:16] <jibel> any question ?
[16:16] <zul> do you guys need help with that?
[16:16] <jibel> hggdh, ^
[16:17] <hggdh> jibel: sorry, I was not aware I was to test 10.04.2
[16:17] <jibel> :-)
[16:17] <jibel> zul, okay we need help then
[16:17] <hggdh> I spent last week on hardy...
[16:18] <zul> jibel: ok ill bring it up in the meeting tomorrow then
[16:18] <jibel> zul, thanks.
[16:18] <skaet> jibel, how are we going to get testers to work around the maverick/natty bug for creation of 10.04.2 iso cds and usbs?   Is there some good documentation on this somewhere?
[16:20] <jibel> skaet, For testers I'll send an email to explain the issue, and point them to the bug report.
[16:21] <skaet> jibel, thanks - that will help.   I'll make sure its documented in release notes.
[16:22] <jibel> skaet, it's not a nice bug but the workaround is easy.
[16:22] <skaet> thanks jibel.    any other questions?
[16:23] <skaet> [TOPIC] Image build status and plans  - cjwatson
[16:23] <MootBot> New Topic:  Image build status and plans  - cjwatson
[16:24] <cjwatson> as far as I know most things are green, with the exception of my screwup that broke the Xubuntu images and Ubuntu DVDs (i386 only).  The code bug is fixed and rebuilds are in progress.
[16:25] <cjwatson> The only build issue I'm aware of is that the following images are oversized: Xubuntu desktop amd64, Xubuntu desktop powerpc, Xubuntu desktop powerpc+ps3, Xubuntu alternate powerpc
[16:25] <cjwatson> oh, and Kubuntu desktop i386
[16:25] <cjwatson> I don't know how much we care about those, and about which ones
[16:26] <skaet> charlie-tca, Riddell,  ^^ ?
[16:28]  * skaet looks around..
[16:28] <charlie-tca> we will live with it if I can't get them dow
[16:29] <charlie-tca> I will get someone to look at the Xubuntu desktop amd64 and try to squeeze it down
[16:30] <charlie-tca> The other ones, I guess I don't really card so much
[16:30] <skaet> charlie-tca, ok, thanks.   If we can't squeeze, we'll need to release note, so we should probably open a bug to track.
[16:30] <charlie-tca> I will do that
[16:31] <skaet> cjwatson.  I'll follow up with Riddell about Kubuntu after the meeting about Kubuntu
[16:31] <skaet> any other questions?
[16:32] <skaet> thanks cjwatson
[16:32] <skaet> [TOPIC] any new business?
[16:32] <MootBot> New Topic:  any new business?
[16:32] <skaet> or issues/concerns about 10.04.2?
[16:33] <skaet> ok,  thanks for attending,  we'll go back to the regular agenda next meeting.
[16:33] <pitti> I'm terribly sorry, missed the time
[16:33] <skaet> #endmeeting
[16:33] <MootBot> Meeting finished at 10:33.
[16:33] <charlie-tca> Thanks, skaet
[16:34] <ara> thanks skaet
[16:34] <skaet> thanks bjf, sconklin, ara, jibel, cjwatson, charlie-tca
[16:35] <marjo> thx skaet
[16:35] <jibel> thanks for chairing skaet
[16:35] <skaet> thanks marjo
[16:36] <pitti> skaet: any fires which I need to put out in lucid?
[16:40] <skaet> pitti,  thanks,  can you look at the bugs that jibel raised, and make sure no kitten killers in them,  cjwatson's handling the image rebuilds.  I'll paste them or the log (if available) to you directly
[16:41] <pitti> skaet: thanks, will have a look once you paste
[18:00] <jjohansen> \o
[18:00]  * jdstrand waves
[18:01] <JackyAlcine> o/
[18:01]  * micahg waves
[18:01] <mdeslaur> hellow
[18:01] <kees> \o
[18:02]  * jdstrand waits for sbeattie 
[18:05] <jdstrand> ok, let's get started
[18:05] <jdstrand> #startmeeting
[18:05] <MootBot> Meeting started at 12:05. The chair is jdstrand.
[18:05] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[18:05] <jdstrand> The meeting agenda can be found at:
[18:05] <jdstrand> [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting
[18:05] <MootBot> LINK received:  https://wiki.ubuntu.com/SecurityTeam/Meeting
[18:05] <jdstrand> [TOPIC] Review of any previous action items
[18:05] <MootBot> New Topic:  Review of any previous action items
[18:05] <jdstrand> only thing from last week is the ia32-libs. aiui, mdeslaur is doing lucid and sbeattie is working on the rest. Since it is assigned I don't think we need to bring it up every week
[18:06] <jdstrand> [TOPIC] Weekly stand-up report
[18:06] <MootBot> New Topic:  Weekly stand-up report
[18:06] <mdeslaur> jdstrand: I'm doing hardy, not lucid
[18:06] <jdstrand> mdeslaur: oh, I actually knew that. not sure why I put lucid...
[18:07] <jdstrand> anyhoo
[18:07] <jdstrand> I'll go first
[18:07] <jdstrand> I am on community this week
[18:07] <jdstrand> Mozilla updates are imminent, so I will be testing and publishing firefox, xul and tbird soon
[18:07] <jdstrand> I got sidetracked last week by several things and made no progress on dbus/apparmor or dbus-glib update. Hopefully I can start on it again
[18:07] <jdstrand> Some of those things were profiling gnome thumbnailers, a chromium update, writing aa-disable, patch piloting and a number of meetings
[18:08] <jdstrand> I'm hoping this week will fair slightly better. micahg starts tomorrow, so I'll be handing off all the browser/mozilla stuff to him in the coming weeks
[18:08] <jdstrand> I think that's it from me
[18:08] <jdstrand> kees: you're up
[18:08] <mdeslaur> oh sweet! hi micahg!
[18:08] <micahg> hi mdeslaur
[18:09] <kees> okay
[18:09]  * jdstrand is *very* happy to have micahg coming on board :)
[18:09]  * kees hugs micahg
[18:09]  * micahg hugs kees back
[18:09] <kees> I've got a few USNs coming up this week
[18:10] <kees> I'm in happy-place, which means I'm going to try to knock out the gcc testsuite change upstreaming. maybe some more %pK patches to LKML
[18:10] <kees> honestly, the gcc stuff will probably eat most of my time. running the suite is crazy time-consuming
[18:11] <kees> I'd like to try to find people to fix the firefox and chromium hardening stuff
[18:11] <kees> afaik, firefox is still not PIE in natty, and chromium ARM has PIE disabled too
[18:11] <mdeslaur> :(
[18:12] <kees> that's it from me...
[18:12] <jdstrand> kees: is that not PIE for armel/firefox or all archs?
[18:13] <kees> jdstrand: non-PIE for all archs with firefox
[18:13] <jdstrand> bummer
[18:14] <kees> yeah, it's a gcc-4.5 regression. following-up with chrisccoulson has bubbled to near the top of my todo list finally.
[18:14] <jdstrand> micahg: would you be willing to work with chrisccoulson to conditionally set PIE for non-armel? (assuming it works for non-armel)
[18:14] <jdstrand> then kees can continue to try to find people to fix armel stuff
[18:14] <micahg> jdstrand: it was failing before on all arches, but sure :)
[18:14] <jdstrand> meh
[18:14] <chrisccoulson> jdstrand, it fails on i386
[18:14] <jdstrand> well, if it was failing everywhere, it sounds like chrisccoulson already knows about it
[18:15] <kees> yeah, I'm pretty sure the chromium and firefox PIE issues are separate
[18:15]  * jdstrand nods
[18:15] <chrisccoulson> jdstrand, the behaviour is unique to the i386 implementation of TLS
[18:15] <chrisccoulson> but i need to refresh my memory on the issue again ;)
[18:16] <jdstrand> chrisccoulson: cool. it would be great to not regress on this issue for natty release
[18:16] <jdstrand> I would think upstream would be interested in this too...
[18:16] <kees> the arm-pie-chromium issue is technically not a regression (it's been disabled for a while). I just want to also get it fixed.
[18:17] <jdstrand> kees: actually, on lucid it was only recently turned off
[18:17] <jdstrand> I'm not sure if that is because only recently people noticed or because it recently broke
[18:17] <kees> jdstrand: right, but my understanding was that it was due to chromium version bumps
[18:18] <kees> i.e. it became new enough that someone hit it. or something. dunno; this is why I want to spend some time to investigate and delegate. :)
[18:18] <jdstrand> I don't know the cause. I do consider disabling pie in a security update, regardless of version bumping, as a regression
[18:18] <jdstrand> of course, there isn't a lot we can do there...
[18:18]  * kees nods
[18:18] <jdstrand> kees: I appreciate you looking into it! :)
[18:19]  * sbeattie is here, reading scrollback
[18:20] <mdeslaur> my turn?
[18:21] <jdstrand> mdeslaur: as kees mentioned that was it from him, why don't you go
[18:21] <mdeslaur> So, I'm currently testing fuse updates, and will release them once lucid's fuse package in -proposed gets released
[18:22] <mdeslaur> Besides that, I need to take a look at ffmpeg
[18:22] <mdeslaur> and still have work to do on apparmor-profiles
[18:22] <mdeslaur> I also have some gnome-screensaver fixes I want to push to natty, and possibly SRU into lucid and maverick
[18:22]  * sbeattie saw mdeslaur's commits to the apparmor-profiles tree; nice start!
[18:23] <mdeslaur> and there was another package I wanted to work on this week...but...it slips my mind right now (d'oh!)
[18:23] <mdeslaur> that's it from me
[18:24]  * sbeattie takes his turn.
[18:24] <sbeattie> I have a krb5 update that I'll release once this meeting is over.
[18:24] <sbeattie> I have an openssl update for right afterward, though I need to do a little more testing with it.
[18:25] <sbeattie> I made some progress on apparmor release stuff, and have more to do on that this week.
[18:25] <sbeattie> That's pretty much it for me.
[18:26] <jdstrand> sbeattie: I've seen a lot of those reviews. some of it should be quite nice (especially the opensuse stuff you slurped in)
[18:26] <sbeattie> thanks.
[18:27] <jdstrand> micahg: I know you only officially start tomorrow, but is there anything you'd like to mention? typically we mention what we hope to work on in the coming week, and occasionally work that we did last week as it might affect this week (or that is particularly cool)
[18:28] <jdstrand> micahg: it is ok to say 'no'. I know I just sprung this on you :)
[18:28] <micahg> Finish getting set up, I'd like to start looking at the webkit update, 1.2.7 is out
[18:29] <jdstrand> sounds great
[18:29] <jdstrand> [TOPIC] Miscellaneous and Questions
[18:29] <MootBot> New Topic:  Miscellaneous and Questions
[18:29] <jdstrand> One thing sbeattie mentioned to me last week is vendor-sec tracking
[18:29] <jdstrand> I'll let him expand on it if he wants, but the basic idea is that we treat it as quite ad-hoc
[18:30] <jdstrand> whoever happens to see something, mentions it
[18:30] <jdstrand> eg, the last postgresql update
[18:30] <jdstrand> we knew about it early, but we didn't let pitti know, and basically reacted to it
[18:31] <jdstrand> I wonder if this could be improved more?
[18:31] <jdstrand> we could try to use the CVE-2011-NNNX method more often
[18:31] <mdeslaur> jdstrand: did you have anything in mind?
[18:31] <kees> I've found the vsec threads difficult to really "triage" until they're reached a certain stage
[18:32] <jdstrand> mdeslaur: not really, this is just open for discussion (beyond what I just mentioned)
[18:32] <jdstrand> kees: yes, I tend to agree
[18:32] <jdstrand> I also don't tend to update my embargoed branch very often...
[18:32] <kees> sometimes there are weeks between something being brought up and it being remotely actionable.
[18:33] <jdstrand> true. that was indeed the case with postgres, iirc
[18:33]  * sbeattie wondered if he just needs better management of that particular email folder.
[18:34] <jdstrand> perhaps it would be best to identify any problems with the current system, and then see if we actually need to fix them
[18:35] <jdstrand> sbeattie: are there particular things you find lacking?
[18:36] <sbeattie> the concern I have is us not noticing stuff that comes through vendor-sec, because it comes in a mish-mash of stuff we don't as much about, because there's other active threads that are developing fixes that "drown" out other issues.
[18:36] <sbeattie> s/don't/don't care/
[18:37] <jdstrand> I think that is a valid concern
[18:37] <jdstrand> what do others think?
[18:37] <sbeattie> Was wondering if there was a light-weight way of coordinating that we can ignore certain threads, should watch others for deveopling fixes, etc.
[18:37] <micahg> maybe if one person can keep an eye on vendor-sec each week?
[18:38] <kees> traditionally this is the person doing "triage"
[18:38] <jdstrand> we could do something like what we do with USN assignments-- a one line assessment in a file...
[18:38] <jdstrand> I'm not sure how helpful that would be...
[18:38] <mdeslaur> I think vendor-sec is important enough that we all should be looking at it, not just the triage person
[18:38] <jdstrand> mdeslaur: what are your thoughts?
[18:38] <kees> I don't exactly see a specific problem to solve yet.
[18:38] <mdeslaur> bug, that being said
[18:39] <kees> mdeslaur: that's fair
[18:39] <jdstrand> I was on triage last week
[18:39] <mdeslaur> I think we should make sure to call out any packages we see that appear there, and make sure someone takes responsability for it
[18:39] <jdstrand> I mentioned only one item
[18:39] <mdeslaur> whether it be in a file or not
[18:40] <mdeslaur> if we notice that we're skipping some, I think we can move into doing the CVE-XXXX stuff, or even a simple file
[18:40] <jdstrand> in a way, this is preassignment
[18:40] <mdeslaur> so, in the case of postgresql, what exactly did we do wrong there?
[18:41] <mdeslaur> we didn't notify pitti?
[18:41] <jdstrand> mdeslaur: in that case, pitti told us about it, when we actually had the info
[18:41] <mdeslaur> when we saw something about postgresql, did we just assume pitti would be telling us about it?
[18:42] <jdstrand> well, without divulging too much info
[18:42] <jdstrand> there was a question posted regarding notifying upstream
[18:42] <jdstrand> the answer was that upstream was notified
[18:43] <jdstrand> then it sat there until pitti told us about it
[18:43] <jdstrand> but, the issuing wasn't critical
[18:43] <jdstrand> s/issuing/issue/
[18:43] <jdstrand> we all probably read the thread
[18:43] <jdstrand> I know I wasn't thinking it was a huge deal at the time
[18:43] <mdeslaur> I'm sorry...I though pitti _was_ postgresql upstream
[18:44] <jdstrand> mdeslaur: he is the debian maintainer
[18:44] <mdeslaur> oh!
[18:44] <jdstrand> he does not do upstream postgresql afaik
[18:44] <mdeslaur> ah, I thought he did, so I'm mistaken
[18:44] <jdstrand> mdeslaur: and he happens to provide updates for -security out of tradition
[18:44] <mdeslaur> so...we couldn't have told him anyway
[18:44] <jdstrand> yes we could have
[18:44] <mdeslaur> hmm
[18:45] <jdstrand> we are allowed to let developers who work on it know
[18:45] <jdstrand> eg, kernel embargoed stuff
[18:45] <jdstrand> they just have to know not to talk about it, etc
[18:45] <jdstrand> in fact, pitti may have already known
[18:45] <jdstrand> which I think is part of the problem in this particular case-- we didn't communicate
[18:46] <jdstrand> but then again, I wasn't thinking it was world-burning and a 0day we had to jump on
[18:46] <jdstrand> at least, as I recall from reading the thread from weeks ago
[18:46] <jdstrand> so, ok, let's drive this to resolution
[18:47] <jdstrand> a) is there a problem? b) if there is, is the answer pre-assigning?
[18:47] <jdstrand> I'm not sure there is a problem, per se
[18:47] <sbeattie> jdstrand: are you sure you're thinking of the right vuln? I don't see a "thread" about it, just a singlepost.
[18:48] <jdstrand> hold on
[18:51] <jdstrand> sbeattie: yes, I was. I responded privately
[18:52] <jdstrand> so, postgres aside
[18:53] <jdstrand> 12:47 < jdstrand> a) is there a problem? b) if there is, is the answer pre-assigning?
[18:53] <jdstrand> kees, sbeattie, mdeslaur: ^ opinions?
[18:53] <jdstrand> micahg: ^
[18:54] <sbeattie> right, the fear is that, if we didn't this particular postgresql issue until we were prompted from pitti, are we letting other things slip through the cracks.
[18:54]  * micahg doesn't know whether or not there's a problem yet :)
[18:54] <sbeattie> heh
[18:54] <mdeslaur> well, whatever slips through the cracks simply shows up after CRD
[18:54] <mdeslaur> it's not as if we're skipping updates altogether
[18:54] <jdstrand> right
[18:55] <mdeslaur> of course, we need to publish stuff at CRD
[18:55] <jdstrand> and we jump all over the world-burning stuff
[18:55] <mdeslaur> and I think everybody needs to read vendor-sec and make sure someone's got the ball on things we spot
[18:56] <jdstrand> well, that is a gray area
[18:56] <mdeslaur> I think postgresql is a bad example in this case
[18:56] <jdstrand> I mean, we don't need to jump on a low issue
[18:56] <mdeslaur> yes, and there are low issues on vendor-sec...and universe stuff also
[18:56] <jdstrand> many mediums we probably don't, though it is nice if we do
[18:57] <jdstrand> alright
[18:57] <kees> perhaps we should put stuff into the embargoed tree once a CVE has been assigned on vsec, or if it's serious enough with a very short CRD
[18:57] <jdstrand> kees: that is a good idea
[18:57] <jdstrand> if it has a CVE, put it in embargoed
[18:57] <jdstrand> tbh, we should have ben doing that all along
[18:57] <jdstrand> I certainly haven't
[18:57] <kees> right
[18:57] <kees> but they develop so slowly that it can span triagers
[18:58] <jdstrand> yeah
[18:58] <jdstrand> well, so we need to be updating our embargoed tree daily probably
[18:58] <kees> so perhaps the current triager should add CVEs, and update changing CRDs
[18:58] <jdstrand> and then as we see CVEs assigned in vsec, we add them
[18:58]  * jdstrand nods
[18:58] <mdeslaur> and skip everything that doesn't have a CVE? :P
[18:58] <kees> but, as mdeslaur says, we should probably all read it
[18:58] <jdstrand> others can check/follow-up with the triager
[18:59] <mdeslaur> seems to be that doesn't solve the problem :P
[18:59] <jdstrand> agreed
[18:59] <jdstrand> I think it does
[18:59] <jdstrand> it is tracked
[18:59] <jdstrand> it'll show up in cve_todo
[18:59] <mdeslaur> only stuff that has a CVE gets tracked
[18:59] <kees> mdeslaur: if something is coming fast without a CVE, it should get the CVE-2011-NNN1 or whatever
[18:59] <jdstrand> mdeslaur: or high priority stuff
[18:59] <jdstrand> then we use the convention kees just mentioned
[19:00] <mdeslaur> ok, so triager adds everything he sees to embargoed tree
[19:00] <jdstrand> when a cve is assigned, we bzr mv CVE-2011-NNN1 ...
[19:00] <jdstrand> I don't think so
[19:00] <kees> (and update the internal name)
[19:00] <jdstrand> all CVEs assignments
[19:00] <jdstrand> s/CVEs/CVE/
[19:00] <jdstrand> high priority or higher get CVE-2011-NNNX
[19:00] <jdstrand> but that is my opinion
[19:00] <mdeslaur> ok
[19:00] <mdeslaur> what about stuff not in main, we ignore it?
[19:01] <jdstrand> mdeslaur: yes
[19:01] <jdstrand> (again, my opinion)
[19:01] <jdstrand> well, ignore it in terms of CVE-2011-NNNX
[19:01] <jdstrand> ok
[19:02] <mdeslaur> jdstrand: so if it does get a cve, but is not in main, we add it to embargoed anyway?
[19:02] <jdstrand> I think that is fair
[19:02] <jdstrand> most of that ends up in oss-security anyway
[19:02] <jdstrand> (ie, not much maintenance work)
[19:02] <mdeslaur> ok
[19:02] <jdstrand> to summarize:
[19:02] <jdstrand> if has CVE with CRD, add to embargoed
[19:03] <jdstrand> if no CVE, but is officially supported and high priority, add to embargoed
[19:03] <jdstrand> (with CVE-YYYY-NNNX)
[19:03] <jdstrand> everyone reads the list
[19:03] <mdeslaur> ok
[19:03] <jdstrand> the triager adds
[19:04] <sbeattie> +1 from me
[19:04] <mdeslaur> what about CVE with no CRD?
[19:04] <jdstrand> kees, mdeslaur, sbeattie, micahg: ^ will that address the concerns/issues appropriately?
[19:05] <kees> mdeslaur: skip it, I think.
[19:05] <jdstrand> I agree
[19:05] <kees> jdstrand: sounds good; I've updated the Duties page
[19:05] <jdstrand> kees: thanks! :)
[19:05] <mdeslaur> ok, +1
[19:05] <jdstrand> well
[19:05] <jdstrand> actually, if it is supported, with a CVE but no CRD, we should ad it
[19:06] <jdstrand> otherwise skip
[19:06] <jdstrand> (that way it still shows up in our cve todo list
[19:06] <jdstrand> )
[19:07] <jdstrand> which gives us an opportunity to be reminded to followup with upstream, etc
[19:09] <jdstrand> kees, mdeslaur, sbeattie: ^
[19:09] <jdstrand> micahg: ^
[19:09] <mdeslaur> jdstrand: that sounds good
[19:09] <kees> +1
[19:09] <micahg> sounds good to me
[19:09] <kees> (Duties re-updated)
[19:09] <sbeattie> +1
[19:09] <jdstrand> micahg: you are not under my fingertips just yet :)
[19:09] <jdstrand> cool
[19:09] <jdstrand> ok
[19:09] <jdstrand> so, that is it from me
[19:10] <jdstrand> does anyone have any other questions or items to discuss?
[19:10] <micahg> just an update on Mozilla stuff
[19:10] <micahg> no release today, on a day-to-day slip
[19:10] <jdstrand> thank goodness
[19:11] <jdstrand> I was going to be hardpressed to get it tested by eod
[19:11] <micahg> jdstrand: I wouldn't bother, there might be new builds
[19:11] <jdstrand> micahg: what is the new date?
[19:12] <micahg> jdstrand: when it's ready :)
[19:12] <jdstrand> micahg: and that is tentatively when? :)
[19:12] <micahg> jdstrand: they didn't say, I think they're hoping for tomorrow, but can't promise
[19:13] <jdstrand> well, then I need to test the current builds
[19:13] <jdstrand> otherwise I'll be hours to a day late
[19:13] <jdstrand> (depending on when they push it out)
[19:13] <jdstrand> anyhoo
[19:13] <jdstrand> I'll talk to you in #ubuntu-mozillateam
[19:14] <jdstrand> I think that's it then
[19:14] <jdstrand> thanks everyone! :)
[19:14] <jdstrand> #endmeeting
[19:14] <MootBot> Meeting finished at 13:14.
[19:14] <mdeslaur> thanks jdstrand!
[19:15] <sbeattie> jdstrand: thanks!
[19:15] <micahg> jdstrand: thanks :)
[19:16] <kees> thanks jdstrand :)
[19:16] <jdstrand> sure!