18:01:16 #startmeeting 18:01:16 Meeting started Thu Nov 3 18:01:16 2011 UTC. The chair is cjwatson. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot. 18:01:16 18:01:16 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:01:17 * stgraber waves 18:01:28 [TOPIC] Action review 18:01:41 o/ 18:01:47 hey mdz, how are you? 18:01:55 pitti, doing well, how is UDS? 18:01:56 can somebody remind me where the last minutes were? 18:02:15 soren says he couldn't find them 18:02:43 no idea 18:02:51 who lead last time, stgraber? 18:02:55 or was it cancelled? 18:03:09 the auto-generated minutes would be somewhere in http://ubottu.com/meetingology/logs/ubuntu-meeting/ i believe 18:03:19 http://ubottu.com/meetingology/logs/ubuntu-meeting/2011/ubuntu-meeting.2011-10-20-18.00.moin.txt 18:03:27 thanks 18:03:31 http://ubottu.com/meetingology/logs/ubuntu-meeting/2011/ubuntu-meeting.2011-10-20-18.00.log.txt 18:03:36 cjwatson to setup a survey for a new Technical Board meeting time 18:03:44 done last night 18:03:59 I've had five responses, will wait for the sixth 18:04:06 I'm not sure how to answer it. 18:04:20 It depends on whether it will be revisited once DST kicks in again. 18:04:31 Let's agree now that it will, then 18:04:37 Cool. 18:04:43 is it possible to update it somehow? 18:04:51 (I don't see how) 18:04:53 the existing poll? 18:05:00 my response to it 18:05:14 I filled it out with DST wiggling in mind, although it only affects two slots 18:05:38 hover over your name, there's an edit link to the left 18:05:40 this poll definitely stretched the limits of doodle 18:05:51 It affects at least 10 timeslots for me :-/ 18:06:12 yes, it perhaps wasn't ideal for the purpose; I was short on time last night when soren reminded me that I had this action, otherwise I might have looked into other tools 18:06:18 cjwatson: thx 18:06:35 anyway, let's move on 18:06:37 here now, sorry for the delay 18:06:38 I don't know of any better tools. It's a (surprisingly) difficult problem. 18:06:41 stgraber to contact tumbleweed and if he agrees to be on the DMB, add him to the LP team and mailing list 18:06:44 kees: hi 18:06:48 what was the result of the poll? 18:06:57 cjwatson: done, he's now on the DMB 18:07:03 oh, you're waiting for one more 18:07:12 mdz: waiting for soren's input; I'll post to the list once I've collated that 18:07:15 i've found http://www.timetomeet.info/ to be quite good for this, fwiw 18:07:22 or rather reviewed doodle's collation 18:07:30 cjwatson: Well, it also seems pitti wants to change his response. 18:07:32 * pitti updated his slots for DST adaption then, currently set up for winter time 18:07:33 broder: thanks, hopefully we'll remember to try that next time :) 18:07:44 Ah, ok, nm :) 18:07:45 soren: done now 18:07:50 stgraber to update the term of the DMB members to 2 years 18:07:58 done 18:08:00 stgraber to add the new members to the ARB 18:08:18 done for the team, still waiting for jono to contact IS to make me the admin for the mailing-list 18:08:34 so we currently need to Cc all the members which is a bit annoying, I'll poke him in person :) 18:08:43 * kees listens to the sounds of typing in antigua1 18:08:51 :) 18:08:54 stgraber: OK, thanks 18:09:31 I think broder agreed to us deferring "Opening backports pocket pre-release" to next meeting, as it's a recent submission and there's been no e-mail discussion yet - is that OK with everyone? 18:09:49 * kees nods 18:10:02 yup 18:10:04 yep 18:10:05 (although broder is in Antigua 1 here ...) 18:10:33 i'm fine with that. i was mostly hoping for an opportunity to resolve objections in person with the benefits of lower latency. but we've been kicking this around for a while now, so there's no sudden rush 18:10:48 if we have time at the end we'll come back to it then 18:10:50 [TOPIC] LTS cadence 18:11:03 That would be me. 18:11:23 The e-mail says it all, really. 18:11:24 the stage there changed a bit with going from 3 to 5 years on non-server, but in practice it sounds fine to me 18:11:33 everyone was pretty much operating on that assumption anyway 18:11:41 I don't think there's much point in us revisiting the Debian angle that Mark mentioned by e-mail; we've already tried going down that road and frankly it did not go well 18:11:42 including our own internal planning processes 18:11:54 and there's still a way out with an one-time change confirmed by CC/TB 18:12:20 The motivation was a discussion in OpenStack where we talked about designating every 4th release an LTS one to follow Ubuntu, but someone pointed out that Ubuntu doesn't promise anything about this cadence. 18:13:11 since LTSness is really Canonical-backed, I'm not sure the TB has any control over the LTS cadence exactly. 18:13:13 I do think we should leave ourselves a bit of flexibility, but promise to give plenty of notice if we exercise it, and have a damn good reason 18:13:15 cjwatson: When was this? 18:13:29 cjwatson: yes, that option was explicitly in the mail 18:13:30 soren: Debconf in Caceres 18:13:42 cjwatson: Er... Year? 18:13:49 I can bring you up to speed out of band if you like; it's a fairly long story 18:13:52 2009 I think 18:13:55 and we need that, there might always things coming up that make a plannet LTS impractical 18:14:20 cjwatson: Ok. Since then, Debian has switched to a time based release model, right? Not as strict as ours, but close, IIUIC. 18:14:32 time-based freeze 18:14:34 soren: well, s/has switched/wants to/ 18:14:35 Ah, yes. 18:14:39 and not time-based releases 18:14:43 important distinction :) 18:14:47 * skaet nods 18:14:51 Ok, sure, let's take this off-line. 18:14:57 but Debian has different "ready for release" metrics and planning processes than we 18:15:27 while it's true that Canonical offers the LTS commitment, if the Ubuntu project offered strong and reasoned advice on timing I think Canonical would accommodate it 18:15:29 and with my Debian hat on, I don't see Debian do predictable time-based releases in the next two years or so 18:15:38 Good points. 18:15:39 we have not had reason to do so up to now 18:16:14 and setting expectations in advance does have its own value 18:16:23 kees: OTOH, Mark explicitly asked the TB 18:16:53 pitti: I don't meant to see TB has no influence, but we don't strictly control it 18:16:59 s/see/say 18:17:02 I think that, for users, the benefits of predictability outweigh the potential advantages of being able to tweak the timing to align with Debian et al 18:17:17 Well, if we all agree, whose decision it actually is is a bit of a moot point :) 18:17:21 kees: right; but if we come up with a good reason why e. g. 14.04 would be bad, but 14.10 would be better, then I'm pretty sure that this will strongly be considered at least 18:17:23 I think overall, the current cadence should be maintained if for no other reason that it seems to work well and people have come to expect it. 18:17:30 mdz +1 18:17:50 but yeah, if there's a compelling reason to change, sure. 18:17:59 the example I've been using this week is a friend of mine who supports academics, and is keen on the new five-year desktop support combined with our LTS cycle because that means he can always support a desktop for the lifetime of a PhD without major version upgrades 18:18:10 it'll just need to be very loudly announced since many organizations now expect the current cadence. 18:18:14 that's the kind of thing that a predictable cycle enables 18:18:29 kees: Right. And this is really about making sure that is the case. 18:18:37 kees: frankly, I think we'd need to do this even without a formal commitment by now 18:18:38 (well, with some optimism attached ...) 18:18:44 kees: ...because there hasn't so far been any promise that this is how it'll be. 18:18:48 * kees nods 18:19:13 I think the proposal is reasonable as it's pretty much what our users expect and we have a way of changing it if really really needed 18:19:16 pitti: right, we have an implied commitment 18:19:38 I'm hearing consensus here; does anyone feel we need to vote? 18:19:50 seems unanimous to me 18:20:03 +1 18:20:04 yeah, sounds like we all agree there 18:20:09 +1 18:20:20 +1 18:20:24 (obviously) 18:20:30 but if we got asked to sign off this, we might just as well :) 18:20:32 (there's no bot listening, but...) +1 18:20:48 [AGREED] ratify two-year LTS cadence as proposed by soren+mark 18:21:15 #agreed ratify two-year LTS cadence as proposed by soren+mark 18:21:34 #agree I think 18:22:02 apparently it accepts both but gives no feedback 18:22:15 ah 18:22:17 anyway, bot-fettling aside, I'll follow up by mail as part of doing minutes 18:22:26 [TOPIC] Streamlining package set management 18:22:35 (anyone know what this one is about?) 18:22:37 * Laney comes over 18:22:53 https://lists.ubuntu.com/archives/technical-board/2011-October/001104.html 18:23:29 cjwatson: In case you want to go back to the meeting time discussion at some point, I've finished filling in my data. 18:23:33 ah, right, added a link to the agenda 18:25:03 so - my view (as the person who's done a lot of packageset manipulation) is that formal DMB votes approve developers for categories of permission, but it's fine for DMB members to use common sense in tweaking permissions for trivial package name changes and the like 18:25:13 (or whoever owns the team) 18:25:45 from my perspective it's a change to require having this be discussed and aged on devel-permissions, but personally I think that's a good change, as it provides an audit trail 18:25:48 yes, that seemed like the de facto status quo 18:25:59 Q.E.D. 18:26:17 (I've often done things like adding linux-backports-modules-$VERSION to the kernel set based on IRC requests) 18:26:20 This proposal is basically about making official things that we've been doing, at least for the 3 first points, the last one is a very good idea though 18:26:23 IMHO an important change is that we start requiring people to provide criteria 18:26:35 something that we can assess change requests against 18:26:36 I think three days of aging would be unnecessary for things like that 18:26:44 not sure how to codify that 18:26:45 currently the definitions of the sets are rather loose 18:26:48 asking for criteria sounds reasonable 18:26:58 which makes acting on changes ad-hoc 18:27:00 though there will certainly continue to be lots of wiggle room and judgement calls for what's appropriate to add 18:27:18 cjwatson: we could add some exception for cases where we have a versioned source package? 18:27:20 another example is things like Till having approved upload access to things that are obviously part of the printing subsystem 18:27:33 as in, version in the source package name 18:27:39 although in that case perhaps some more aging is appropriate since there is often more overlap between what people maintain 18:27:41 Is there any way to see when a package gets added (and possibly by whom)? 18:27:42 * kees wonders about revocation a bit 18:27:56 stgraber: that is the kind of thing that can go in a description 18:28:13 soren: not afaik 18:28:20 If changes to package sets were announced somewhere, I wouldn't mind if there were no aging period. 18:28:33 devel-permissions@ is meant to be exactly that 18:28:47 it is just as easy to remove a package, so I guess that will be enough in case of objections 18:28:53 Laney: "I think three days of aging would be unnecessary for things like that" so that's for an exception to the 3 days rule when it's just a change to the source package name (when containing the version) 18:28:54 pitti: I meant automatic announcement when the deed is actually done. 18:28:58 and if something really gets objections, we can always revert 18:29:02 pitti: Does that land on devel-permissions? 18:29:07 soren: no, that's quiet 18:29:20 ok, no need for aging then 18:29:29 DMB member responds on -permissions to confirm that they did it 18:29:34 I'm not sure what audit trail Launchpad keeps 18:29:35 (or whoever) 18:29:37 It's just easier to revert something if you know there's something to revert. 18:29:41 yeah, I think foo-1.0 -> foo-2.0 is really just a technical change, not a social/policy change at all 18:29:49 I would be happy to take an action to chase that down if people think it's important to have 18:29:58 yeah, unless it gets abused or there a lots of reverts, I don't see a reason for the waiting period. 18:30:03 (though not to fix it ...) 18:30:04 soren: yes, that's why I meant it should be on d-p@ 18:30:16 pitti: Gotcha. 18:30:41 is the DMB now able to take action on all package set manipulation requests that they care about? 18:30:41 in general it's a lot smoother to add new packages right away, as it unblocks devs 18:31:03 or is there still a requirement for somebody with some other demigod bit to do it? 18:31:04 TB still owns cli-mono for some reason 18:31:20 actually it still owns a few: http://people.canonical.com/~stgraber/package_sets/precise/ 18:31:25 damnit. changing owners is a pain, it requires a LOSA 18:31:26 but for ones we own, sure 18:31:38 I can do the other ones for now 18:31:41 being on both TB and DMB 18:32:00 yep, if you need TB action as a workaround, feel free to mail technical-board@ too 18:32:01 though this really should be fixed on LP's side 18:32:04 yes 18:32:05 anyway 18:32:31 do we have something to vote on here? agree Laney's proposal minus the aging period? 18:33:08 Sounds good to me. 18:33:20 +1 18:33:21 +1 18:33:22 something like "changing package sets is under the DMB's discretion as long as changes get announced to d-p@"? 18:33:50 +1 18:33:57 +1 18:34:01 ta 18:34:24 #agreed DMB discretion for changing package sets by common sense as long as they announce it 18:34:45 (sorry, I want to keep moving here as we have a couple more things) 18:35:00 [TOPIC] Proposal for criteria to become and remain a recognized derivative flavor, and proposal for criteria to designate flavor release as LTS 18:35:07 [LINK] https://wiki.ubuntu.com/RecognizedDerivatives 18:35:19 this is something skaet has been working on, and perhaps she can present it briefly 18:35:32 We need to clarify some processes on the criteria for a set of images to be considered a recognized derivative and what is necessary for a derivative to be designated LTS. 18:35:32 Have worked up some proposals for criteria and would like to get them reviewed by TB and any necessary updates made; so we have a place to point folk when the questions come up. 18:35:47 we already discussed it yesterday briefly, and via mail before, and this looks very thorough and clear to me 18:36:53 skaet, this looks very good, we were overdue for a document like this 18:36:56 my main comment (which I've made in person etc.) is that I think this is often based on a general soft sense of how a flavour is interacting with us etc.; I think we normally tend to be fairly well aligned on that, from what I can tell 18:37:10 the main change is having some formal way that a very well-organised flavour can access the LTS processes 18:37:30 is there anything in here which is new, as opposed to codifying existing common practice? 18:37:39 "Minimum 1 person sponsored at UDS" ? does that mean they must always be at UDS? 18:37:44 one thing I'd like to add is that a derivative must have at least N non-LTS releases before 18:37:47 skaet: ^ 18:37:47 mdz: the LTS bit is new 18:37:54 to get some proven track record 18:37:54 still reading 18:37:56 recognized flavor part was codifying, what I observed through lubuntu 18:38:00 LTS is new 18:38:11 kees: I talked with skaet about that - I think that meant that Canonical will always be prepared to offer such sponsorship 18:38:11 which is needed to get some acquaintance with their developers, etc. 18:38:20 cjwatson, I agree with your comment, and would support swapping "criteria" for "guidelines" to reflect that 18:38:22 maybe we should be a bit clearer there 18:38:29 ah-ha 18:38:32 * skaet nods 18:38:35 mdz: yes, that would be good 18:38:48 some of the wording on image testing is somewhat new as well 18:38:57 ("flavour QA lead") 18:39:11 we had that in the last release 18:39:22 indeed, sorry, that's what I meant by "somewhat" 18:39:38 :) 18:40:00 There is sometimes a separation in responsibility. 18:40:14 did you get any substantive comments from folk maintaining existing flavours? 18:40:20 In some cases the contact also serves as the lead, but this may not always be the case. 18:40:54 Then we should clarify that they can be the same person, but that's a minor detail. 18:40:59 no issues raised from stgraber and riddell when I reviewed it with them. 18:41:27 Have talked about it with some others, but haven't done the 1:1 with all. 18:41:46 soren, ok. 18:41:47 OK, I'd like to hear feedback from at least one non-Canonical person since sometimes they have different perspectives ;) 18:41:55 but that sounds plausible so far 18:42:53 cjwatson, representing derivatives, you mean? 18:42:59 yes 18:43:09 Have talked to charlie-tca as well, and he was positive. 18:43:22 It happened in the UDS session earlier this week. 18:43:41 i believe highvoltage was in the room as well 18:43:53 having something codified seems like a good step forward, and this is close enough to existing practice that I'm not too fussed 18:44:00 anything which turns out to be problematic we can change 18:44:04 broder, yup he was. Thanks for the reminder. 18:44:23 I agree with pitti's comments about N non-LTS releases; I expect the TB wouldn't approve something that was too new and untried, but it's good to set expectations 18:44:26 the main thing I'd like to avoid is to bless a brand new derivative as LTS right away 18:44:36 right 18:44:39 just because it happened to pop up at that time 18:44:45 * skaet nods 18:45:00 * highvoltage catches up with conversation 18:45:06 and if we have a document which codifies that, I think that should be in 18:45:40 skaet: the document doesn't actually seem to mention that LTSness requires TB signoff; does it? 18:46:03 I mean, does it intend to? 18:46:05 pitti, use of word criteria implies it. 18:46:16 second bullet point says TB approval 18:46:27 oh, ignore me 18:46:31 grep fail, sorr 18:46:34 y 18:46:42 I think it's implicit in "recommendations for Tech Board consideration" anyway, but sure 18:46:56 skaet: s/criteria/guidelines/ as suggested earlier? 18:47:02 cjwatson: I thought the bold text would go away once that document gets approved 18:47:45 cjwatson, yes. 18:47:48 so, with TB approval the "have N previous releases" is kind of implied, but might still be good to set an expecation 18:47:49 pitti: fair 18:47:50 For Edubuntu, we're going to apply for LTS status with some notes on how we plan to support it for 5 years. It's probably a good excercise even if it's not strictly required. 18:47:51 with N=2 or so? 18:48:22 time check: we have 12 minutes and I have a hard stop (another meeting after this). is there anything further after this topic? 18:48:33 five years, really? gosh. I wasn't expecting non-Canonical flavours to manage that. (not that I inherently object, it just seemed like a big ask) 18:48:49 There's a choice of saying 3 or 5 years 18:48:49 mdz: same here 18:48:59 Possibly talking about the meeting time. 18:49:03 I wouldn't mind getting back to broder's proposal if we have time 18:49:04 pitti, ouch, another meeting? 18:49:12 mdz: UDS 18:49:16 soren: I'm not going to have time to look at the doodle output before the end of this meeting 18:49:20 No worries. 18:49:22 oh, right, you're in a nearby TZ now :-) 18:49:23 not and pay attention 18:49:31 cjwatson: that's what LTS means now, isn't it? 18:49:41 highvoltage: you have the option of either three or five years 18:49:52 if that's not clear, we should clarify this document 18:50:06 hmm, imho 3 years would actually be more appropriate for Edubuntu. <- stgraber? 18:50:08 (or 18 months, non-LTS) 18:50:17 let's take the edubuntu LTS length discussion separately 18:50:22 we don't have to do that now :) 18:50:35 shall we vote on the document then? 18:50:36 yes, sorry for noise :) 18:50:50 [VOTE] approve flavour support guidelines as adjusted by comments in this meeting 18:50:50 Please vote on: approve flavour support guidelines as adjusted by comments in this meeting 18:50:50 Public votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me) 18:50:56 +1 18:50:56 +1 received from pitti 18:50:56 highvoltage: I'll discuss that with you and alkis and we'll propose something for the next TB meeting 18:51:00 +1 18:51:00 +1 received from stgraber 18:51:02 +1 18:51:02 +1 received from cjwatson 18:51:03 +1 18:51:03 +1 received from mdz 18:52:01 +1 18:52:01 +1 received from soren 18:52:22 +1 18:52:22 +1 received from kees 18:52:32 [ENDVOTE] 18:52:32 Voting ended on: approve flavour support guidelines as adjusted by comments in this meeting 18:52:32 Votes for:6 Votes against:0 Abstentions:0 18:52:32 Motion carried 18:52:47 Thanks! 18:52:49 [TOPIC] Opening backports pre-release 18:52:53 I'll make the changes and remove draft. 18:52:56 skaet: thanks to you, nice writeup! 18:53:00 I don't know if we'll have time to finish this, but perhaps we can start 18:53:19 i realize this has potential to be a complicated topic; i wasn't expecting decisions today 18:53:27 I'm somewhat concerned about skew in developer attention 18:53:33 and possibly what users are in practice testing 18:53:57 with NotAutomatic: yes set on backports, users would have to work to be testing everything in backports 18:54:14 regarding skew in general, I think we could really use some tools to report on this kind of thing; to some extent we already have this problem with (e.g.) oneiric-proposed vs. precise 18:54:39 right. Laney and i discussed something vaguely similar to a MoM configuration between release and backport pockets 18:55:02 so we could watch for that skew 18:55:05 upload privileges: the original TB approval of direct uploads to -backports explicitly applied only to -core-dev 18:55:09 I don't remember that being changed 18:55:23 I can definitely upload… 18:55:30 right, technically ... 18:55:31 i may have confused requirements to be on ~ubuntu-backporters and the requirements for direct uploads 18:55:37 i've never tried a direct upload myself... 18:55:48 we probably ought to revise that anyway, that was in like 2005 or something 18:55:56 or at least review 18:56:14 i certainly have a fair amount of uncertainty about what the technical enforcements are on backports; i'd prefer to discuss what we'd like to see implemented and we can be responsible for aligning our implementation with that 18:56:36 ...assuming that i can sell the board on the idea in the first place, of course 18:56:40 archive admin workload: TBH I'm not worried about that, our job is to provide that service (among others) and we should ensure that we have enough people to do so 18:57:00 I think the technical enforcements on backports are by this point incoherent 18:57:13 perhaps it would be worth starting from scratch and saying how we'd like it all to work 18:57:19 er, that's what you said 18:57:24 vociferous agreement then 18:57:50 I'm pretty sure they aren't coherently written down in one place, at any rate 18:57:50 sorry, can we continue this next time? really need to leave 18:58:17 OK, and we can follow up by mail too; I have to move on too, per UDS clockwork 18:58:23 same here 18:58:36 thanks a lot to everyone for attending, and to UDS folk for skipping the plenaries to do so 18:58:48 thanks, good meeting! 18:58:55 thanks 18:59:00 mdz, kees: we're missing you here ;-) 18:59:17 #endmeeting