21:02:24 #startmeeting 21:02:24 Meeting started Mon Mar 5 21:02:24 2012 UTC. The chair is cjwatson. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 21:02:24 21:02:24 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:03:01 the agenda does not appear to have been updated following the last meeting; it appears that the ARB agenda item was discussed and eventually passed over to the ARB for further resolution 21:03:21 but I only skimmed the logs very quickly just before this meeting; can somebody confirm? 21:03:25 correct 21:03:43 and the ARB chose to maintain a single source package for each set of lens+scopes 21:03:50 so no policy change is required 21:04:47 OK. I do not see any pending actions; there's the discussion on the list about what to do about brainstorm, and there was a trademark policy item which has been turned into a ticket 21:05:03 #topic agenda detangling 21:05:37 AFAICS what the agenda *should* consist of is the Ubuntu Studio LTS item 21:05:53 to which there've been no followups on the list thus far 21:06:02 anyone want to dispute or amend that agenda? 21:06:19 i have a quick backports related questoin that i just sent mail about if you guys don't mind looking quickly 21:07:57 cjwatson, no dispute 21:08:13 ditto 21:08:13 broder: OK, I've appended that 21:08:22 wiki is now resembling accurate 21:08:30 #topic Ubuntu Studio LTS Plan Proposal 21:08:43 #link https://lists.ubuntu.com/archives/technical-board/2012-February/001214.html 21:08:56 Scott Lavender is usually scott-work, but does not appear to be here 21:09:18 * stgraber digs for his germinate script, trying to get a unique list of source packages for ubuntu studio 21:10:01 the proposal is a bit bare, and perhaps we ought to follow up with how to flesh it out better, if we can't track down Scott just at the moment (I pinged him in -devel) 21:11:31 it doesn't designate key support contacts, nor which upstream packages are of particular interest other than Xfce (per https://wiki.ubuntu.com/RecognizedFlavors) 21:11:47 I'm also a bit worried about getting this LTS application so late in the cycle 21:12:34 That doesn't really worry me, tbh. 21:13:11 http://paste.ubuntu.com/870509/ list of source packages found in ubuntustudio and that aren't part of xubuntu or ubuntu (as they've now moved to XFCE I thought checking against xubuntu+ubuntu made sense) 21:13:19 personally I'd like to have a clear idea of which developers are active 21:13:21 There was ambiguity around the whole LTS'ing of flavours, so it's hardly surprising that flavours are later to the party. 21:13:34 scott-work has generally referred to himself as an organiser rather than a developer, IME 21:15:24 soren: my worries are mostly related to the very limited possibility of removing/changing package selections to reduce their ubuntustudio-specific package for an LTS as any of these will need a freeze exception and matching updates to documentation, translations, installer slideshow, ... 21:15:50 Are there any other specific comments? It feels to me as though it would be best to have an initial response by mail, and then Scott can beef up the proposal and be prepared for the next meeting 21:16:27 (Ubuntu Studio doesn't have its own installer slideshow) 21:16:50 soren: though looking at the list I pasted before, it looks fairly short (doesn't pull a full additional language or something) so I don't think they'd actually have much they could do to reduce the list 21:16:51 cjwatson, I have nothing to add 21:16:53 I'm happy to collate comments from here and respond 21:17:23 they have a lot of AV packages that aren't elsewhere, but that's kind of the point of Ubuntu Studio 21:17:36 aha 21:17:37 hey scott-work 21:17:42 hello :) 21:17:52 thanks for showing up at short notice; sorry we weren't organised about the agenda in advancec 21:18:09 I'll /msg you the discussion so far 21:18:11 stgraber: Hang on, are you suggesting that only the packagesets will be in the pool at 5 years? 21:18:23 scott-work: http://paste.ubuntu.com/870519/ is what we've said so far 21:18:30 oh, apparently cjwatson was faster ;) 21:18:31 ah, I'll stop then :-) 21:18:40 no, I was just getting started 21:19:34 Daviey: no, but I expect flavours to support the packages that they are the only one shipping for the length of support they want to provide as LTS 21:20:13 Daviey: we have no mechanism to trim the pool that way, and no plans to implement such a mechanism :) 21:20:16 Daviey: Edubuntu for example got rid of some java packages to avoid pulling 150 dependencies or so that we'd ultimately be responsible for as we were the only ones using them 21:20:17 sorry, work grabbed my attention, reading pastebin now 21:20:25 stgraber: that seems irrelevant, the same could be said for desktop or server.. Server, at least, will likely touch packages outside the packageset after 18m's 21:20:37 cjwatson: good :) 21:20:41 Daviey: it's the standard we've held other flavours to 21:20:48 ok 21:21:04 it isn't a problem if flavours overachieve 21:21:16 what we want to know is whether they can cope with the minimum requirements 21:21:23 Oh. 21:21:29 * Daviey relurks. 21:21:34 Daviey: we want a commitment for the packages that are specific to a flavour, if people want to do more than that, they're always welcome to :) 21:21:49 i can address a few of the points already made when it is convenient 21:21:55 absolutely, please go ahead 21:22:59 as far as active developers, there aren't many really although micagh has been a huge help, both in terms of helping but furthering my education as well 21:23:16 themuso (luke) is active from time to time, but less and less honestly 21:23:48 i am not a proficient or efficient developer, but i am mostly solely responsible for any ubuntu studio specific packages being modified lately 21:23:56 and as such i would presume to be the key contact 21:24:04 * micahg won't commit to fixing stuff for Ubuntu Studio for the LTS, but is happy to help sponsor stuff for them 21:24:16 how do you plan to cope with doing security support for the range of packages specific to Ubuntu Studio? 21:24:38 bearing in mind that less and less tends to come "for free" as the release ages 21:24:52 i would posit that most of the A/V specific packages are actually maintained in debian, however 21:25:04 i don't have hard data to back that up specifically 21:25:17 cjwatson: that isn't in response to your security question 21:26:23 cjwatson: i don't honestly know what is involved in the security support for these packages, so i'm not sure i can formulate an appropriate response currently 21:26:58 micahg: do you think you could work with scott-work to help him establish what's involved there? it's a fairly key part of any LTS plan 21:27:24 cjwatson: sure 21:27:27 thanks 21:28:22 maintenance in Debian is great for the development release, but stable releases often require backporting things to a version that isn't anything that Debian is maintaining 21:28:55 cjwatson: i attempted that last LTS with ardour, i understand :) 21:29:33 "fumbling" with that might be a more apt description, though 21:29:47 OK; can we follow up by mail, then? Sorry again that this is a bit haphazard 21:30:05 i should also point out that ubuntu studio does now have it's own slide show installer 21:30:13 21:16 (Ubuntu Studio doesn't have its own installer slideshow) 21:30:16 :-) 21:30:19 oh, wait 21:30:31 "does now" probably not a typo for "does not", which is how I read it ... 21:30:49 right, I see it now, sorry for the misinformation 21:32:50 hehe :) 21:32:50 let's move on, then, and we'll get this firmed up by mail and return to it next time 21:33:14 #topic Opening backports pre-release (redux) 21:33:16 #link https://lists.ubuntu.com/archives/technical-board/2012-March/001224.html 21:33:41 broder: I think this is to some extent a matter of you amending your own summary :-) 21:34:20 the way I read your original summary is that we have to EITHER (a) have component isolation for builds in the backports pocket OR (b) rebuild binary packages if and when we copy from backports to the development release 21:34:48 hmm, i see your point :) 21:34:53 and what I'm hearing is that you intend to do (b) by way of re-uploadin 21:34:54 g 21:35:19 (which is the only way to do it anyway - we can't do source-only copies within the same archive, since backports shares a pool with everything else) 21:36:08 my recollection of the irc discussion was that we agreed on (a) before we decided to re-upload, and didn't re-evaluate (a) after that, but i could be misremembering 21:36:37 but if you read the history differently, i can run with that 21:37:03 well I think (a) was simply a consequence of not re-uploading 21:38:52 ok. in that case i'll withdraw my request for clarification and move forward without turning on component isolation 21:38:56 * cjwatson waits to see if anyone disagrees with this interpretation 21:39:21 * stgraber agrees 21:40:17 * soren too 21:40:38 OK, carried nem con then 21:40:46 I have a question which may be slightly tangential to this in that who is responsible for fixing any issues with the new uploads in the dev release 21:40:47 #topic AOB 21:40:49 oh 21:40:57 micahg: whoever uploaded them? :-) 21:41:11 micahg: you mean for backports? 21:41:15 (hm, which indicates it can't be a bulk archive admin task) 21:41:45 cjwatson: well, the rebuilds could be sponsored for the last person in the changelog, but that won't always be right 21:42:05 we could always lie in the changed-by line :) 21:42:27 "Uploaded to new dev release by Evan Broder on behalf of Micah\n\n -- Micah Gersten " 21:42:40 I'm only really particularly bothered about somebody getting any build failure mails and being responsible for fixing those 21:42:51 and for that, the signer of the package will get them 21:42:54 if nothing else 21:43:03 right 21:44:58 the reason I ask is for the rest of backports, the backports team "sponsor" the uploads, and I don't think we want to be responsible for the new toolchain failures :) 21:46:02 well, it can't be the backport requestor, so I don't see who else is possible 21:46:23 if it's really due to the new toolchain, then you can hand that off to whoever maintains the relevant bit of the toolchain? 21:46:31 cjwatson: for regular backports it's fine, I'm speaking specifically of the pre-release uploads 21:46:55 what happens if an archive rebuild uncovers a main FTBFS that didn't fail because it was copied forward at the start of the release? 21:47:00 this seems analogous 21:47:01 we could just make (fsvo) whoever did the pre-release upload do another one 21:47:11 cjwatson: well, I'm speaking more of collateral damage in toolchain updates, not that it's broke per se 21:47:28 broder: in that case it's the same source package with the same uploader who presumably actually knows something about the package 21:48:12 cjwatson: right, but there's a commitment from someone (the project? cnaonical? i'm not sure) that all of main builds at release time. who fixes that up if a package breaks due to external changes? the til? 21:48:33 broder: well, I'm not sure I agree, normally, a backport has to land in the devel release and then is getting backported, we're giving people a jump on getting the backport, but that shouldn't necessarily remove the other end of it 21:48:44 the TIL, the +1 maintenance team, package set owners, whoever happens to come along and get bothered by it ... 21:49:09 in many cases we simply don't have a single throat to choke right now, so I'm not too concerned that there wouldn't be one in this case, TBH 21:49:34 sure, I'd just like it to be clear if there's such an expectation for responsibility 21:49:48 not necessarily that we be able to hunt people down 21:49:56 the +1 maintenance team was an experiment for 12.04; if it continues beyond that, it may well be a suitable ongoing target for at least coordination of this kind of thing, if not first-line responsibility 21:50:19 my gut is that a package immediately FTBFSing after being re-built from backports is fairly equivalent to a package not immediately FTBFSing because its binaries were copied and then discovering that it FTBFSes later during an archive rebuild test or something 21:50:25 micahg: my preference, if possible, is that uploading a pre-release backport would constitute a promise to deal with the upload to the development release once it opens as wewll 21:50:30 *well 21:50:37 that way the line of responsibility is obvious 21:50:43 sounds good to me 21:51:20 we should have a report to ensure that all the necessary uploads get done, and if somebody is failing to do the ones they promised to do, we'll just have somebody do it for them eventually and eat the slight confusion caused by that 21:51:41 I expect that in many cases they'll be superseded by Debian syncs anyway 21:52:20 any other business before we close? 21:52:36 The meeting or the agenda item? 21:53:09 both I guess (considering the current agenda item is AOB) 21:53:17 * stgraber doesn't have anything else 21:53:28 I guess we should talk about the meeting time again. 21:53:38 DST ends in the US this weekend, doesn't it? 21:53:46 And in Europe at the end of MArch. 21:53:55 Or am I a month too early? 21:53:58 * soren checks 21:54:15 Nope, that seems accurate. 21:54:20 if somebody wants to organise another doodle or $better_tool, that would be awesome 21:54:33 bagsy not it, as we used to say in primary school 21:54:44 And what did you mean? :) 21:54:51 "" 21:54:59 Ah :) 21:55:32 Well, March is special, isn't it? 21:56:01 For the next meeting, we'll be at an odd offset (Europe <-> US). 21:56:28 yeah, I think next meeting we should just stick to the current UTC time, then change for the next one if needed 21:56:45 stgraber: Just what I was trying to express as well. Thanks :) 21:57:02 (as the current meeting is in the middle of my afternoon, I don't mind if being an hour earlier or later for DST changes) 21:57:20 stgraber: Cool. 21:57:38 but we could probably change the meeting time a bit if it makes it better for people in Europe (where our current meeting time is kind of late) 21:57:54 Then we can do a Doodle for the first meeting after all of EUrope and US has gone DST. 21:58:02 sounds good 21:58:04 stgraber: doesn't make much difference for me TBH 21:58:12 don't know about pitti 21:58:25 soren seems to cope? 21:58:39 Yeah, this is not too bad. 21:59:48 I remember planning these things were particularly annoying for the server team as our meetings were adjacent to the kernel team's, so if one team moved, the other had to, too. I guess we have the luxury of not having to worry about that. 22:00:19 So maybe this will be as simple as sticking with the current local time and just chaning the UTC time? 22:00:35 I'll send an e-mail to ask. We might not have to do the doodle at all. Yay. 22:00:59 all right, thanks all 22:01:01 #endmeeting