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