#title #ubuntu-meeting: Technical Board Meeting Meeting started by stgraber at 18:06:41 UTC. The full logs are available at http://ubottu.com/meetingology/logs/ubuntu-meeting/2011/ubuntu-meeting.2011-11-17-18.06.log.html . == Meeting summary == *New meeting time ''ACTION:'' stgraber to update https://wiki.ubuntu.com/TechnicalBoardAgenda with the new meeting time (stgraber, 18:10:24) ''ACTION:'' stgraber to update the Ubuntu engineering calendar with the new meeting time (stgraber, 18:11:55) *Opening backports pocket pre-release ''LINK:'' https://lists.ubuntu.com/archives/technical-board/2011-November/001122.html (stgraber, 18:12:29) ''ACTION:'' broder to update the plan for pre-release backports and send update to the TB mailing-list (stgraber, 18:43:10) *Scan the mailing list archive for anything we missed (standing item) *AOB *Chair for next meeting Meeting ended at 18:46:59 UTC. == Votes == == Action items == * stgraber to update https://wiki.ubuntu.com/TechnicalBoardAgenda with the new meeting time * stgraber to update the Ubuntu engineering calendar with the new meeting time * broder to update the plan for pre-release backports and send update to the TB mailing-list == Action items, by person == * broder ** broder to update the plan for pre-release backports and send update to the TB mailing-list * stgraber ** stgraber to update https://wiki.ubuntu.com/TechnicalBoardAgenda with the new meeting time ** stgraber to update the Ubuntu engineering calendar with the new meeting time == People present (lines said) == * cjwatson (42) * pitti (38) * stgraber (31) * broder (26) * micahg (9) * meetingology (6) * ubottu (1) == Full Log == 18:06:41 #startmeeting Technical Board Meeting 18:06:41 Meeting started Thu Nov 17 18:06:41 2011 UTC. The chair is stgraber. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot. 18:06:41 18:06:41 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:06:44 anyway, so next meeting will be in 11 days then, Monday evening? 18:06:57 #topic New meeting time 18:07:08 let's start with that then :) 18:07:50 so based on the doodle poll, the new meeting time is now Monday at 21:00 UTC 18:08:03 it's not ideal for me, but we knew that; I can manage it 18:08:07 Monday 2100 only cuts into the first sleep hour, so that still WFM during winter time; I'd appreciate if we could move it back an hour during summer 18:08:18 perhaps we can just tie it to London time instead of UTC? 18:08:19 right, I proposed polling again at the next DST change 18:08:33 sometimes things shift round more than that so I think it's better to repoll 18:08:40 would make it easier to have a permanent definition which doesn't keep messing up personal schedules 18:08:47 if it's done by somebody vaguely efficient rather than me then it shouldn't take too long :) 18:08:49 ok 18:08:56 actually I'd prefer to have occasional shifting around to share the pain ... 18:09:02 heh, or that :) 18:09:25 I also prefer polling again in 6 months, so we can maybe find a better spot or indeed share the pain a bit :) 18:09:29 so I guess that's settled 18:09:58 I'll update the wiki, anything else that needs changing? 18:10:24 #action stgraber to update https://wiki.ubuntu.com/TechnicalBoardAgenda with the new meeting time 18:10:24 * meetingology stgraber to update https://wiki.ubuntu.com/TechnicalBoardAgenda with the new meeting time 18:10:52 wiki and maybe the Ubuntu engineering calendar 18:11:05 how do we update the calendar? 18:11:23 if you don't have access, ask Michelle 18:11:38 ok, I'll have a look 18:11:55 #action stgraber to update the Ubuntu engineering calendar with the new meeting time 18:11:55 * meetingology stgraber to update the Ubuntu engineering calendar with the new meeting time 18:12:09 #topic Opening backports pocket pre-release 18:12:18 so, back to backports 18:12:29 https://lists.ubuntu.com/archives/technical-board/2011-November/001122.html 18:12:58 hello everyone 18:13:09 points 2 and 3 seem no different to me than for "normal" backports 18:13:17 and for point 4, yes, definitively source-only 18:13:20 I'd like to dig into upload privileges a little bit 18:13:44 as discussed at the tail end of last meeting 18:13:44 for point 4 I think the requirements for early backport uploads should be like for regular ones, i. e. include a check-mir run perhaps? 18:13:47 i think we concluded last time that nobody was totally sure how the backports pocket worked currently, so we should probably talk about how we would *want* it to work, and adjust accordingly 18:13:51 right 18:14:10 originally, the TB said "only ubuntu-core-dev gets to do manual uploads to backports" (regardless of whether that's what's actually implemented in LP) 18:14:14 my main point for discussion is the first bullet point 18:14:40 actually, i realized later that source-only copies aren't an option, because we can't have 2 different builds with the same version number in the archive 18:14:55 I would prefer to just say that any developer with upload privileges to the package in question can upload it to -backports, and that we'd generally expect -backporters to review that 18:15:19 that won't require adding another celebrity to LP or whatever, and it seems a reasonable policy 18:15:22 with upload privileges in the source or the target release? 18:15:33 target I guess 18:15:41 that's the one you're changing after all 18:15:56 right, and only core-devs could introduce a new package in -backports then? 18:15:56 and for pre-release backports, there is no source release, at least within ubuntu 18:15:57 I agree that this means we might actually have to maintain the package sets for older releases 18:16:07 stgraber: ubuntu-dev, I think 18:16:15 if we just went with the natural LP policy 18:16:21 sorry, n 18:16:29 ubuntu-core-dev or motu (you have to have component upload privileges) 18:16:55 sounds good 18:17:13 as all of these uploads will land in unapproved anyway, I don't see a problem with ~ubuntu-dev being technically able to upload 18:17:38 should we allow new sources after feature freeze though? IMHO, those could wait until the following release 18:17:46 (as the usual script will not work, there's nothing to backport from) 18:17:52 micahg: i think allowing new sources is a huge benefit of this plan 18:18:00 ^ agree 18:18:11 I would like to allow ~ubuntu-backporters to be able to do queue management on the backports pocket 18:18:13 because previously there was an extended period where there was no way to get new sources into the archive, which is difficult for upstreams that are new to our cycle 18:18:29 this will, I think, require some work in LP, but it seems eminently worthwhile 18:18:37 that way we wouldn't impose much extra archive admin load 18:18:58 and it would also get rid of the AA steps for the regular backports, makign the process smoother 18:19:15 but it's not a blocker for this policy, anyway 18:19:20 pitti: well, except for backporthelper 18:19:36 micahg: do we need that? 18:19:45 for no change backports? 18:19:53 I thought these would be pretty much normal uploads, just with a differetn target (devrelease-backports) 18:19:55 re pocket copies: we could simply copy source in universe and reupload things in main. that would probably be good enough. 18:20:14 cjwatson: you mean source+binaries in universe? 18:20:18 ys 18:20:20 *yes 18:20:40 I'd prefer rebuilding it (new toolchain, FTBFS check, etc.) 18:20:43 allowing backporters to do queue management sounds spiffy. we already have that open request to LP to allow for separate queue privileges by packetset, right? i wonder if it's worth rolling this request into that 18:20:51 or new library ABIs 18:21:50 cjwatson: is there a specific reason that AA need to do backports with backport-helper/mass-syncs instead of us doing them with backportpackage? i guess we bypass the new queues that way? 18:22:13 I think it just meant we didn't have to do more checking 18:22:29 pitti: you're probably right 18:22:33 * micahg thought it was the same reason for using sync-helper and why the LP API is prefered for sync's, no round trip through dev machines 18:23:00 once -backporters starts handling the queue admin, I wouldn't mind revisiting that 18:23:14 I'd prefer we do that first though 18:23:25 ok 18:23:30 that way -archive doesn't have to check that it's really the same package with changelog tweak 18:24:01 ah, right, because the queue doesn't actually give you the diff you care about. makes sense 18:24:34 last time I raised a concern about skew in developer attention, but on reflection, I think it's mostly different developers involved 18:24:57 and having a mechanism for people to get things into -backports early ought to take some pressure off the release team and allow us to have a higher-quality release in general 18:25:21 as long as you folks are sensible about saying "no, this really ought to go into the release 'cos it's broken as it is" 18:25:30 which AFAICS you're already doing with SRUs 18:25:44 yeah, "this should be an SRU" is one of our stock answers 18:25:59 i think extending that to "this should be a freeze exception" should be pretty natural 18:27:07 with these, do you actually expect a huge influx of packages which are backported pre-release? 18:27:31 my gut feeling is that we are talking about a magnitude of ten here 18:28:06 yeah, i don't think i expect it to be massive 18:28:53 or at least not initialy 18:30:04 as for your first point, can we have a report which shows us when backports get obsoleted by release uploads? 18:30:13 and/or an email notification? 18:30:28 we have that in the pending-sru.html script already, should be simple to port 18:30:33 well, if it 18:30:40 it shows us when an SRU gets superseded by a -security upload 18:30:55 in that case we need a merge or a new backport 18:31:01 yeah, and i've got a similar report for backports whose source was superseded by a security/SRU update 18:31:10 ugh, if it's going into -proposed, we wouldn't want to remove that from -backports, right, since it'll be post release? 18:31:11 something similar would also be useful for the existing backports 18:31:11 i can definitely do that 18:31:19 e. g. you backport final version, then it gets a security update 18:31:22 this should be re-backported, too 18:31:41 oh, that's what you mean... 18:31:54 right - http://people.ubuntuwire.org/~broder/rebackporter/rebackports.json is the report i'm currently generating 18:32:03 micahg: no, I mean if you upload to -backports at FF time, and the same package gets FFEd later on with a higher version 18:32:27 ah, right, makes sense to remove, but would we want to do that for -proposed as well or just the release pocket? 18:32:31 if that could alert the backporter team, or it auto-files bugs, or whatever, I'd be entirely happy with the proposal 18:32:57 micahg: I think for -updates/-security uploads we generally want to update the backport as well 18:33:02 for release, it might be a merge 18:33:12 i'm ok with having it auto-file bugs 18:33:15 as we have both a newer version and a (potentially totally unrelated) fix to the release package 18:35:00 +1 on auto-file 18:35:19 auto-file with a tag, yes 18:35:20 sorry, I need to run 18:35:47 with the "superseded package" being flagged, and doing new uploads for main uploads into +1, I'm happy 18:35:51 thanks for your input, pitti 18:38:02 is there anything else we want to discuss on that topic? we unfortunately don't have quorum today, so I'd recommend to document the plan based on the dicussion we just had and vote on the final proposal at the next TB meeting 18:38:37 right, we're now inquorate; I think I'm happy with this but it's significant enough that I think we should document what we have and not try to do it on a bare quorum anyway 18:39:02 and there were enough changes suggested here that I think they deserve writing up 18:39:47 ok, so it sounds like (a) bot to monitor and file bugs about skew between -release and -backports, (b) modify -backports to require source-change uploads only from people with permission to upload to that package in other pockets, (c) do rebuilds of either everything or everything from main that gets copied forward to the +1, (d) possibly follow up with lp on allowing queue management granularity 18:39:47 by pocket? 18:39:49 yeah, even with pitti's +1, we're only at 3/6 members, so better have it well documented, letting the other TB members look at the final proposal and then vote on it in two weeks 18:39:50 anything i missed? 18:40:52 that's everything I mentioned at least 18:41:07 looks good 18:42:17 ok. i can volunteer to write that up and update the list, then 18:42:22 broder: can you update the plan to include these few points and send an updated version to the ML (or a link to a wiki page?)? 18:42:33 sounds like a yes :) 18:42:37 :) 18:43:01 i'm also going to start working on a list of code that needs to be modified to support this 18:43:10 #action broder to update the plan for pre-release backports and send update to the TB mailing-list 18:43:10 * meetingology broder to update the plan for pre-release backports and send update to the TB mailing-list 18:44:26 cool. thanks for the feedback, everyone 18:44:34 broder: thanks! 18:44:39 #topic Scan the mailing list archive for anything we missed (standing item) 18:45:13 didn't find any new topic on there after a quick look. Only a discussion on upstart/lxc and a comment from Kate on bug 174375 18:45:14 Launchpad bug 174375 in Launchpad itself "Distribution drivers permissions may need redesign" [Low,Triaged] https://launchpad.net/bugs/174375 18:45:21 #topic AOB 18:45:24 anything else? 18:45:37 nothing from me 18:45:46 and about to be called away, so :) 18:45:55 #topic Chair for next meeting 18:46:17 I say we stick with kees as he's the next one in alphabetical order, any objection? :) 18:46:48 wfm :) 18:46:57 perfect :) 18:46:59 #endmeeting Generated by MeetBot 0.1.5 (http://wiki.ubuntu.com/AlanBell/mootbot)