21:05:20 <cjwatson> #startmeeting
21:05:20 <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:20 <meetingology> 
21:05:20 <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:27 <cjwatson> https://wiki.ubuntu.com/TechnicalBoardAgenda
21:05:54 <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:56 <mdz> cjwatson, here
21:06:05 <cjwatson> aha, excellent, thanks
21:06:24 <cjwatson> action review: none assuming the prior chair wasn't lying when they updated the agenda :)
21:06:29 <cjwatson> so
21:06:32 <cjwatson> #topic The process of granting a Microrelease Exception for Stable Release Updates - bdmurray
21:06:47 <cjwatson> bdmurray: Are you around and would you like to speak to this?
21:06:54 <bdmurray> cjwatson: yes and yes
21:07:02 <cjwatson> I know there's been a good deal of on-list discussion
21:07:17 <cjwatson> (Some of which I've even had a chance to read ...)
21:07:29 <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:21 <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:25 <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:46 <kees> I think successful SRU history is just an additional piece of evidence, rather than a hard requirement.
21:08:56 <soren> kees: I'd agree with that.
21:09:06 <kees> (it's a very good piece of evidence)
21:09:08 <cjwatson> slangasek has articulated a fairly clear bootstrapping problem in some cases
21:09:13 <kees> yes
21:09:46 <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:50 <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:12 <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:24 <kees> cjwatson: ah, good idea
21:10:27 <cjwatson> (Whether "we" is the TB or the SRU team is a separate issue)
21:10:38 <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:45 <kees> "provisional MRE" then
21:11:09 <cjwatson> There doesn't seem to have been *too* much problem in establishing that by vociferous discussion in this case
21:11:22 <cjwatson> Next time, if we communicate all this a bit more clearly, maybe the uploader can just tell us up-front
21:12:10 <cjwatson> But, indeed, the policy as written says nothing about SRU history, as far as I can see
21:12:22 <cjwatson> So this appears to be guidance, not a policy change
21:12:23 <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:29 <mdz> IIRC the SRU team wanted the TB to make the call on these initially
21:12:39 <mdz> but maybe we should confirm that's still desirable?
21:12:45 <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:54 <cjwatson> mdz: Steve spoke up in favour of continuing that today
21:13:00 <kees> right
21:13:03 <mdz> ah, I'm just reading his email now
21:13:27 <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:22 <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:43 <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:05 <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:11 <cjwatson> slangasek: Do you have anything you'd like to add to what you wrote in mail on this?
21:15:43 <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:52 <cjwatson> kees: That seems like common sense, yes; the MRE process allows creating exceptions, not mandates
21:16:09 <cjwatson> slangasek: While that's true, I'm not sure they'd have found an ~ubuntu-sru-based process any quicker :-)
21:16:11 <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:44 <slangasek> cjwatson: well, I think they might have found it quicker, but only at the cost of the quality of the review
21:17:22 <slangasek> I think developers are much less likely to try to browbeat the TB ;)
21:19:08 <kees> do we have good ways to quickly measure regression-from-update for a package?
21:19:23 <slangasek> not at present
21:19:31 <slangasek> we're hoping errors.ubuntu.com will help with that this cycle
21:19:44 <slangasek> but until that's done, it's all very wishy-washy
21:19:50 <kees> okay.
21:20:33 <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:43 <kees> cjwatson: do we need to vote on nova MRE, or can we just declare a provisional MRE for it?
21:21:20 <cjwatson> We clearly don't need to vote as the policy says that any single TB member can approve
21:21:30 <cjwatson> (Which I assume we'd talk about if there were contention)
21:21:54 <kees> yeah
21:22:04 <cjwatson> This is the chair-as-rules-lawyer principle, right? :)
21:22:15 <kees> okay, then I'll grant a provisional MRE on nova and document it.
21:22:47 <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:52 <kees> does anyone object to my adding some language around provisional MREs and how SRU history is good evidence?
21:22:54 <bdmurray> kees: document it where?  I'm curious about the SRU team will find out about the provisional MREs
21:23:06 <kees> bdmurray: I intend to put it here: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
21:23:08 <cjwatson> https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions seems like the obvious place
21:23:20 <soren> kees: No objection here. Sounds like a good idea.
21:23:24 <cjwatson> #action kees to document provisional MRE for nova, and practice for insufficient-information cases in general
21:23:24 * meetingology kees to document provisional MRE for nova, and practice for insufficient-information cases in general
21:23:47 <cjwatson> Do we feel this is enough to get us moving for the moment?
21:24:20 <bdmurray> I do
21:24:49 <slangasek> apropos of nothing, I think it would also be helpful if the TB would document rationale for the MREs
21:25:20 <slangasek> so that it's documented in the wiki page what the standard is that upstream is expected to continue to meet
21:25:23 <cjwatson> (I think http://paste.ubuntu.com/1059791/ says something but I'm not sure what)
21:25:38 <slangasek> heh
21:26:22 <cjwatson> I think at one point I tried to establish a tradition of linking to the summary of the discussion
21:26:33 <cjwatson> Or somebody did
21:26:54 <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:58 <cjwatson> "
21:27:17 <cjwatson> kees: Or I won't because you have the lock.  Could you?
21:29:20 <kees> cjwatson: sure
21:31:59 <cjwatson> OK, anything more on this topic?
21:32:58 <kees> alright, I've updated https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions if people want to take a quick read
21:33:57 <slangasek> do we have a shared understanding of what "micro-version updates" means there?  does that mean "bugfix-only releases"?
21:34:27 <slangasek> that's how I interpret it anyway, but other devs might understand it otherwise when reading this page
21:35:21 <slangasek> I'm happy with what's there
21:35:22 <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:39 <soren> I suspect it'll almost alwys be bugfix-only releases.
21:35:49 <cjwatson> https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases kind of talks about it
21:36:03 <cjwatson> Slightly circularly but I think the meaning is clear
21:36:34 <slangasek> hmm yes, I think that is problematically circular :)
21:36:46 <bdmurray> should the diff being reviewed part be in the 'sru verification' part of the page?
21:37:17 <slangasek> because that page explicitly talks about microreleases *not* requiring an exception, which is something else
21:37:20 <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:44 <bdmurray> right but that happens before the package is accepted into -proposed not during the verification process
21:37:50 <cjwatson> Oh, yes
21:38:29 <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:29 <kees> slangasek: that matches my understanding as well.
21:40:16 <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:29 <cjwatson> I agree
21:40:40 <stgraber> +1
21:40:57 <soren> +1
21:41:27 <slangasek> sounds like the vote passes - thanks
21:41:53 <cjwatson> Right, let's move on to the rest of the agenda.  Thanks
21:42:05 <cjwatson> #topic Recurring: Brain storm review (Next due: May 2012)
21:42:11 <cjwatson> Whose turn is it?
21:42:41 <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:57 * kees failed terribly at it
21:43:24 <cjwatson> Mine was qualified success at best, but mdz did it very efficiently as I recall
21:43:30 <cjwatson> So we have three left
21:43:54 <soren> I'm not sure what this involves?
21:44:05 <cjwatson> https://wiki.ubuntu.com/TechnicalBoard/BrainstormReview
21:44:23 <cjwatson> Oh yes, pitti did it pretty efficiently too, so two left
21:44:49 <cjwatson> The hypothesis that kees and I are just slackers has not been disproven
21:46:07 <soren> Sure, let me have a stab at it.
21:46:39 <soren> I won't meet the May deadline, though.
21:46:46 <cjwatson> SLACKER
21:46:50 <cjwatson> But great :-)
21:47:11 <stgraber> soren: thanks! did we have a year associated with that deadline? :)
21:47:26 <soren> I'm afraid so.
21:47:26 <cjwatson> I fear that the agenda does
21:47:35 <soren> I'm apparently false.
21:47:37 <soren> false (1)            - do nothing, unsuccessfully
21:47:59 <soren> I've not even started and I'm already almost a month behind schedule.
21:48:02 <soren> Oh, well.
21:49:32 <cjwatson> #action soren to start on brainstorm review
21:49:32 * meetingology soren to start on brainstorm review
21:49:38 <cjwatson> #topic Scan the mailing list archive for anything we missed
21:49:49 <cjwatson> The main thing I see is the LibreOffice MRE
21:49:59 <cjwatson> Which seems to have been slightly stalled on the same discussion as above
21:50:22 <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:30 <cjwatson> kees: ?
21:52:17 <kees> I'm find with it
21:52:21 <kees> *fine
21:52:40 <kees> we should probably do a provisional for it, just to be safe
21:52:53 <cjwatson> It looks like a decent case for a provisional one given your concern about earlier history
21:53:39 <cjwatson> #action kees to follow up to LibreOffice MRE discussion in light of today's debate
21:53:39 * meetingology kees to follow up to LibreOffice MRE discussion in light of today's debate
21:54:18 <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:24 <cjwatson> #topic AOB
21:54:53 <stgraber> nothing here
21:55:06 <cjwatson> going once
21:55:18 <cjwatson> going twice
21:55:41 <cjwatson> *gavel*
21:55:43 <cjwatson> #topic Select a chair for the next meeting
21:55:51 <cjwatson> kees: looks like you're next in rotation - is that OK?
21:56:04 <cjwatson> cal(1) says 2012-07-09
21:56:20 * kees double checks
21:56:33 <kees> yup, I'm around.
21:56:43 <cjwatson> Great
21:56:45 <cjwatson> #endmeeting