[18:04] <jdstrand> o/
[18:04] <tyhicks> hello
[18:04]  * sbeattie waves
[18:05] <jdstrand> let's start
[18:05] <jdstrand> #startmeeting
[18:05] <meetingology> Meeting started Mon Jun 25 18:05:31 2012 UTC.  The chair is jdstrand. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[18:05] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[18:05] <jdstrand> The meeting agenda can be found at:
[18:05] <jdstrand> [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting
[18:06] <jdstrand> [TOPIC] Weekly stand-up report
[18:06] <jdstrand> I'll go first
[18:06] <jdstrand> I've got a short week this week (working today and friday)
[18:06] <jdstrand> I'm on community
[18:06] <jdstrand> I've got libreoffice/oo.o that I am going to try to push out today
[18:07] <jdstrand> I've also got patch piloting this week
[18:07] <jdstrand> and I'm working on an embargoed issue
[18:08] <jdstrand> mdeslaur is off today, but he is in the happy place and I know he is working on several updates
[18:08] <jdstrand> sbc: you're up
[18:08] <jdstrand> meh
[18:08] <sbeattie> hehe
[18:08] <jdstrand> sbeattie: you're up
[18:08] <jdstrand> sbc: nm
[18:08] <sbeattie> I'm in the happy place this week.
[18:08] <sbeattie> I'm fighting with openjdk, trying to backport to older releases.
[18:09] <sbeattie> Otherwise, I'll try to pick up other work items.
[18:09] <sbeattie> that's it for me; micahg, you're up
[18:10] <micahg> sbeattie: I'm finishing up with Thunderbird 13.0.1 (natty) along with a unity-2d update to fix an issue with that, then there's the thunderbird langpack regression that I'll finally fix this week, then webkit all the way aside from helping sbeattie test the openjdk browser plugin when he finishes the backport (fixes a regression for me)
[18:11] <micahg> sbeattie: sorry, didn't mean for the highlight :)
[18:11] <micahg> and that's it I think
[18:11] <tyhicks> I'm in the triage role this week
[18:12] <tyhicks> The pidgin update I had been working on a couple weeks ago had been put on the back burner. I'm actively working it again. Should go out in the early part of this week.
[18:13] <tyhicks> micahg and I will meet after this meeting to discuss ff/tbird testing. I'll likely have some testing to do as the result of that talk.
[18:13] <tyhicks> I've still got merges to do
[18:13] <tyhicks> That should keep me busy for this week
[18:13] <tyhicks> jjohansen: you're up
[18:13] <jjohansen> I've got a short week too (off wed, thurs)
[18:13] <jjohansen> I've still got to finish up on debian bug 676515, my last patch was oopsing
[18:14] <jjohansen> other than that, /me is still trying to get an alpha 1 apparmor out with stacking
[18:15] <jjohansen> I don't think that will happen this week now, but /me will be working towards that
[18:16] <jdstrand> [TOPIC] Highlighted packages
[18:16] <jjohansen> that is it for /me jdstrand back to you
[18:16] <jdstrand> hehe
[18:16]  * jdstrand guessed that was the case
[18:16] <jdstrand> The Ubuntu Security team will highlight some community-supported packages that might be good candidates for updating and or triaging. If you would like to help Ubuntu and not sure where to start, this is a great way to do so.
[18:16] <jdstrand> See https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures for details and if you have any questions, feel free to ask in #ubuntu-security. To find out other ways of helping out, please see https://wiki.ubuntu.com/SecurityTeam/GettingInvolved.
[18:16] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/libdbd-pg-perl.html
[18:16] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/net6.html
[18:16] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/boost1.42.html
[18:16] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/libsmi.html
[18:16] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/xymon.html
[18:16] <jdstrand> [TOPIC] Miscellaneous and Questions
[18:17] <jdstrand> There are a lot of merge opportunities for packages listed in http://people.canonical.com/~ubuntu-security/d2u/. Performing these updates is a great way to help Ubuntu and bolster your developer application.
[18:17] <jdstrand> Does anyone have any other questions or items to discuss?
[18:20] <jdstrand> #endmeeting
[18:20] <meetingology> Meeting ended Mon Jun 25 18:20:20 2012 UTC.
[18:20] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-06-25-18.05.moin.txt
[18:20] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-06-25-18.05.html
[18:20] <jdstrand> sbeattie, micahg, tyhicks, jjohansen: thanks!
[18:20] <jjohansen> thanks jdstrand
[18:20] <tyhicks> thanks jjohansen
[18:20] <micahg> jdstrand: thanks
[18:20] <jjohansen> hehe
[18:21] <sbeattie> thanks
[18:45] <joshuahoover> ralsina: so bug #1017019 appears to be popping up in support requests now...xp and possibly vista users describing the same problem
[18:45] <ralsina> joshuahoover: right
[18:45] <joshuahoover> ralsina: i see you have brian assigned to it, just wanted to let you know that i've seen at least a couple complaints via support about this too
[18:46] <ralsina> joshuahoover: ack
[18:46] <ralsina> joshuahoover: it fails on vista too, it seems
[18:46] <ralsina> joshuahoover: also, wrong channel ;-)
[18:46] <joshuahoover> ralsina: oops
[20:56] <kees> o/
[20:57]  * stgraber waves
[20:59] <soren> o/
[21:00] <cjwatson> here, though just woke up from a nap so excuse idiocy
[21:01] <cjwatson> oh, ugh, and I'm chair
[21:01] <cjwatson> please wait while I put the forgotten sugar in my coffee or else I'm going to be even more stupid
[21:01] <lifeless> I read that as 'I'm chdir'
[21:02] <slangasek> I'm ftrunc
[21:03] <cjwatson> mdz: here?
[21:05] <cjwatson> right, time to start I suppose
[21:05] <cjwatson> #startmeeting
[21:05] <meetingology> Meeting started Mon Jun 25 21:05:20 2012 UTC.  The chair is cjwatson. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[21:05] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[21:05] <cjwatson> https://wiki.ubuntu.com/TechnicalBoardAgenda
[21:05] <cjwatson> I don't see apologies from either mdz or pitti, but at least pitti is apparently offline, so I'll record them as absent for now
[21:05] <mdz> cjwatson, here
[21:06] <cjwatson> aha, excellent, thanks
[21:06] <cjwatson> action review: none assuming the prior chair wasn't lying when they updated the agenda :)
[21:06] <cjwatson> so
[21:06] <cjwatson> #topic The process of granting a Microrelease Exception for Stable Release Updates - bdmurray
[21:06] <cjwatson> bdmurray: Are you around and would you like to speak to this?
[21:06] <bdmurray> cjwatson: yes and yes
[21:07] <cjwatson> I know there's been a good deal of on-list discussion
[21:07] <cjwatson> (Some of which I've even had a chance to read ...)
[21:07] <bdmurray> reading some of the recent micro release exception requests on the mailing list I'm lead to believe that some TB members want to see a history of successful microreleases
[21:08] <bdmurray> However, this isn't an official policy and if this is going to be one a procedure should be created for it
[21:08] <kees> I (erroneously) convinced myself that successful SRU history was a requirement. This isn't documented, and may be counter-productive in some cases.
[21:08] <kees> I think successful SRU history is just an additional piece of evidence, rather than a hard requirement.
[21:08] <soren> kees: I'd agree with that.
[21:09] <kees> (it's a very good piece of evidence)
[21:09] <cjwatson> slangasek has articulated a fairly clear bootstrapping problem in some cases
[21:09] <kees> yes
[21:09] <cjwatson> I think we should be clear that we want a successful history when it's practical, and that we shouldn't institute a permanent MRE until there's been some track record of doing it right
[21:09] <kees> it sounds like the main problem is bundling upstream fixes for bugs Ubuntu may not either have nor have run into yet, and how it is hard/impossible for the SRU team to deal with that.
[21:10] <cjwatson> But I don't see why we can't unblock cases where there's essentially no practical non-microrelease way to update the package by saying "OK, let's give it a try"
[21:10] <kees> cjwatson: ah, good idea
[21:10] <cjwatson> (Whether "we" is the TB or the SRU team is a separate issue)
[21:10] <bdmurray> And the SRU team needs to somehow know that a particular package is a candidate for an MRE and therefore should be evaluated differently
[21:10] <kees> "provisional MRE" then
[21:11] <cjwatson> There doesn't seem to have been *too* much problem in establishing that by vociferous discussion in this case
[21:11] <cjwatson> Next time, if we communicate all this a bit more clearly, maybe the uploader can just tell us up-front
[21:12] <cjwatson> But, indeed, the policy as written says nothing about SRU history, as far as I can see
[21:12] <cjwatson> So this appears to be guidance, not a policy change
[21:12] <stgraber> I'd be happy to see the TB grant a one-time/provisional MRE for such packages to proove themselves, then we can look at the result of that SRU and discuss a standard MRE
[21:12] <mdz> IIRC the SRU team wanted the TB to make the call on these initially
[21:12] <mdz> but maybe we should confirm that's still desirable?
[21:12] <kees> so, in rl discussion with slangasek, the idea of an upstream micro release "breaking $foo number of users and fixing $bar number of users.", and that we (Ubuntu) needs to decide how we're comfortable with the foo/bar ratio.
[21:12] <cjwatson> mdz: Steve spoke up in favour of continuing that today
[21:13] <kees> right
[21:13] <mdz> ah, I'm just reading his email now
[21:13] <cjwatson> On the basis that the SRU team isn't in a much better position to evaluate this than the TB, and is already rather stretched in dealing with specifics of updates
[21:14] <kees> I think the number of things wanting MRE will drop over time, so I'm happy with the TB continuing to be the gate-keeper here. One thing I might like to do is allow the SRU team to _revoke_ an MRE.
[21:14] <cjwatson> These discussions do last a while when they come up, but I've not noticed us having so much in our queue that they've frozen out other work
[21:15] <kees> i.e. if something goes really sideways enough times, the SRU team can require that the MRE process restart for a package.
[21:15] <cjwatson> slangasek: Do you have anything you'd like to add to what you wrote in mail on this?
[21:15] <slangasek> I think the folks that have been requesting the MREs have found the TB process to take longer than they would like; but I also think some of that is an artifact of the process not having been used where it should up to now
[21:15] <cjwatson> kees: That seems like common sense, yes; the MRE process allows creating exceptions, not mandates
[21:16] <cjwatson> slangasek: While that's true, I'm not sure they'd have found an ~ubuntu-sru-based process any quicker :-)
[21:16] <slangasek> i.e. if there had been a clearer understanding on everyone's part that they need to apply for an MRE, they wouldn't have found themselves nearly so squeezed for time
[21:16] <slangasek> cjwatson: well, I think they might have found it quicker, but only at the cost of the quality of the review
[21:17] <slangasek> I think developers are much less likely to try to browbeat the TB ;)
[21:19] <kees> do we have good ways to quickly measure regression-from-update for a package?
[21:19] <slangasek> not at present
[21:19] <slangasek> we're hoping errors.ubuntu.com will help with that this cycle
[21:19] <slangasek> but until that's done, it's all very wishy-washy
[21:19] <kees> okay.
[21:20] <slangasek> we are making an effort now to have the SRU team actively track bugs tagged regression-update; that still relies on bug submitters using the tag correctly
[21:20] <kees> cjwatson: do we need to vote on nova MRE, or can we just declare a provisional MRE for it?
[21:21] <cjwatson> We clearly don't need to vote as the policy says that any single TB member can approve
[21:21] <cjwatson> (Which I assume we'd talk about if there were contention)
[21:21] <kees> yeah
[21:22] <cjwatson> This is the chair-as-rules-lawyer principle, right? :)
[21:22] <kees> okay, then I'll grant a provisional MRE on nova and document it.
[21:22] <cjwatson> There seems to have been no objection to the general notion of provisional MREs, so please document that as a practice for cases where we don't have enough prior information
[21:22] <kees> does anyone object to my adding some language around provisional MREs and how SRU history is good evidence?
[21:22] <bdmurray> kees: document it where?  I'm curious about the SRU team will find out about the provisional MREs
[21:23] <kees> bdmurray: I intend to put it here: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
[21:23] <cjwatson> https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions seems like the obvious place
[21:23] <soren> kees: No objection here. Sounds like a good idea.
[21:23] <cjwatson> #action kees to document provisional MRE for nova, and practice for insufficient-information cases in general
[21:23] <meetingology> ACTION: kees to document provisional MRE for nova, and practice for insufficient-information cases in general
[21:23] <cjwatson> Do we feel this is enough to get us moving for the moment?
[21:24] <bdmurray> I do
[21:24] <slangasek> apropos of nothing, I think it would also be helpful if the TB would document rationale for the MREs
[21:25] <slangasek> so that it's documented in the wiki page what the standard is that upstream is expected to continue to meet
[21:25] <cjwatson> (I think http://paste.ubuntu.com/1059791/ says something but I'm not sure what)
[21:25] <slangasek> heh
[21:26] <cjwatson> I think at one point I tried to establish a tradition of linking to the summary of the discussion
[21:26] <cjwatson> Or somebody did
[21:26] <cjwatson> I'll just edit the page now to say "please link to a summary of the discussion when adding to this list)
[21:26] <cjwatson> "
[21:27] <cjwatson> kees: Or I won't because you have the lock.  Could you?
[21:29] <kees> cjwatson: sure
[21:31] <cjwatson> OK, anything more on this topic?
[21:32] <kees> alright, I've updated https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions if people want to take a quick read
[21:33] <slangasek> do we have a shared understanding of what "micro-version updates" means there?  does that mean "bugfix-only releases"?
[21:34] <slangasek> that's how I interpret it anyway, but other devs might understand it otherwise when reading this page
[21:35] <slangasek> I'm happy with what's there
[21:35] <soren> When the TB gets an application for an MRE, it'll probably say something about what a micro-version update usually contains.
[21:35] <soren> I suspect it'll almost alwys be bugfix-only releases.
[21:35] <cjwatson> https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases kind of talks about it
[21:36] <cjwatson> Slightly circularly but I think the meaning is clear
[21:36] <slangasek> hmm yes, I think that is problematically circular :)
[21:36] <bdmurray> should the diff being reviewed part be in the 'sru verification' part of the page?
[21:37] <slangasek> because that page explicitly talks about microreleases *not* requiring an exception, which is something else
[21:37] <cjwatson> I don't think it needs to be attached to the bug, but I do think that somebody should look it over so that we know what we're getting
[21:37] <bdmurray> right but that happens before the package is accepted into -proposed not during the verification process
[21:37] <cjwatson> Oh, yes
[21:38] <slangasek> my own understanding is that a "new upstream microrelease" is always bugfix-only, and that a developer *may* put such a release through without an exception if they intend to do traditional SRU verification of all the changes individually... and otherwise they can apply for an MRE
[21:39] <kees> slangasek: that matches my understanding as well.
[21:40] <slangasek> if the TB as a whole agrees with that, I'm happy to update https://wiki.ubuntu.com/StableReleaseUpdates to make this clearer
[21:40] <cjwatson> I agree
[21:40] <stgraber> +1
[21:40] <soren> +1
[21:41] <slangasek> sounds like the vote passes - thanks
[21:41] <cjwatson> Right, let's move on to the rest of the agenda.  Thanks
[21:42] <cjwatson> #topic Recurring: Brain storm review (Next due: May 2012)
[21:42] <cjwatson> Whose turn is it?
[21:42] <cjwatson> I know we've had some discussion about how useful this has been; but I'd kind of like to see us give it one more go and see if it's just a matter of personal efficiency :)
[21:42]  * kees failed terribly at it
[21:43] <cjwatson> Mine was qualified success at best, but mdz did it very efficiently as I recall
[21:43] <cjwatson> So we have three left
[21:43] <soren> I'm not sure what this involves?
[21:44] <cjwatson> https://wiki.ubuntu.com/TechnicalBoard/BrainstormReview
[21:44] <cjwatson> Oh yes, pitti did it pretty efficiently too, so two left
[21:44] <cjwatson> The hypothesis that kees and I are just slackers has not been disproven
[21:46] <soren> Sure, let me have a stab at it.
[21:46] <soren> I won't meet the May deadline, though.
[21:46] <cjwatson> SLACKER
[21:46] <cjwatson> But great :-)
[21:47] <stgraber> soren: thanks! did we have a year associated with that deadline? :)
[21:47] <soren> I'm afraid so.
[21:47] <cjwatson> I fear that the agenda does
[21:47] <soren> I'm apparently false.
[21:47] <soren> false (1)            - do nothing, unsuccessfully
[21:47] <soren> I've not even started and I'm already almost a month behind schedule.
[21:48] <soren> Oh, well.
[21:49] <cjwatson> #action soren to start on brainstorm review
[21:49] <meetingology> ACTION: soren to start on brainstorm review
[21:49] <cjwatson> #topic Scan the mailing list archive for anything we missed
[21:49] <cjwatson> The main thing I see is the LibreOffice MRE
[21:49] <cjwatson> Which seems to have been slightly stalled on the same discussion as above
[21:50] <cjwatson> Does anyone want to restart that discussion on-list in light of this?  It looks like the most recent dissent was between kees and pitti
[21:51] <cjwatson> kees: ?
[21:52] <kees> I'm find with it
[21:52] <kees> *fine
[21:52] <kees> we should probably do a provisional for it, just to be safe
[21:52] <cjwatson> It looks like a decent case for a provisional one given your concern about earlier history
[21:53] <cjwatson> #action kees to follow up to LibreOffice MRE discussion in light of today's debate
[21:53] <meetingology> ACTION: kees to follow up to LibreOffice MRE discussion in light of today's debate
[21:54] <cjwatson> Nothing new on community bugs and I have a long enough queue to not want to volunteer to move those LP bugs forward *just* yet, though maybe in future :-)
[21:54] <cjwatson> #topic AOB
[21:54] <stgraber> nothing here
[21:55] <cjwatson> going once
[21:55] <cjwatson> going twice
[21:55] <cjwatson> *gavel*
[21:55] <cjwatson> #topic Select a chair for the next meeting
[21:55] <cjwatson> kees: looks like you're next in rotation - is that OK?
[21:56] <cjwatson> cal(1) says 2012-07-09
[21:56]  * kees double checks
[21:56] <kees> yup, I'm around.
[21:56] <cjwatson> Great
[21:56] <cjwatson> #endmeeting
[21:56] <meetingology> Meeting ended Mon Jun 25 21:56:45 2012 UTC.
[21:56] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-06-25-21.05.moin.txt
[21:56] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-06-25-21.05.html
[21:56] <cjwatson> Thanks all
[21:57] <kees> thanks cjwatson!
[21:57] <stgraber> thanks!