21:02:24 <cjwatson> #startmeeting
21:02:24 <meetingology> 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 <meetingology> 
21:02:24 <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:03:01 <cjwatson> 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 <cjwatson> but I only skimmed the logs very quickly just before this meeting; can somebody confirm?
21:03:25 <stgraber> correct
21:03:43 <stgraber> and the ARB chose to maintain a single source package for each set of lens+scopes
21:03:50 <stgraber> so no policy change is required
21:04:47 <cjwatson> 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 <cjwatson> #topic agenda detangling
21:05:37 <cjwatson> AFAICS what the agenda *should* consist of is the Ubuntu Studio LTS item
21:05:53 <cjwatson> to which there've been no followups on the list thus far
21:06:02 <cjwatson> anyone want to dispute or amend that agenda?
21:06:19 <broder> i have a quick backports related questoin that i just sent mail about if you guys don't mind looking quickly
21:07:57 <mdz> cjwatson, no dispute
21:08:13 <soren> ditto
21:08:13 <cjwatson> broder: OK, I've appended that
21:08:22 <cjwatson> wiki is now resembling accurate
21:08:30 <cjwatson> #topic Ubuntu Studio LTS Plan Proposal
21:08:43 <cjwatson> #link https://lists.ubuntu.com/archives/technical-board/2012-February/001214.html
21:08:56 <cjwatson> 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 <cjwatson> 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 <cjwatson> 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 <stgraber> I'm also a bit worried about getting this LTS application so late in the cycle
21:12:34 <soren> That doesn't really worry me, tbh.
21:13:11 <stgraber> 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 <cjwatson> personally I'd like to have a clear idea of which developers are active
21:13:21 <Daviey> 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 <cjwatson> scott-work has generally referred to himself as an organiser rather than a developer, IME
21:15:24 <stgraber> 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 <cjwatson> 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 <cjwatson> (Ubuntu Studio doesn't have its own installer slideshow)
21:16:50 <stgraber> 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 <mdz> cjwatson, I have nothing to add
21:16:53 <cjwatson> I'm happy to collate comments from here and respond
21:17:23 <cjwatson> they have a lot of AV packages that aren't elsewhere, but that's kind of the point of Ubuntu Studio
21:17:36 <cjwatson> aha
21:17:37 <stgraber> hey scott-work
21:17:42 <scott-work> hello :)
21:17:52 <cjwatson> thanks for showing up at short notice; sorry we weren't organised about the agenda in advancec
21:18:09 <cjwatson> I'll /msg you the discussion so far
21:18:11 <Daviey> stgraber: Hang on, are you suggesting that only the packagesets will be in the pool at 5 years?
21:18:23 <stgraber> scott-work: http://paste.ubuntu.com/870519/ is what we've said so far
21:18:30 <stgraber> oh, apparently cjwatson was faster ;)
21:18:31 <cjwatson> ah, I'll stop then :-)
21:18:40 <cjwatson> no, I was just getting started
21:19:34 <stgraber> 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 <cjwatson> Daviey: we have no mechanism to trim the pool that way, and no plans to implement such a mechanism :)
21:20:16 <stgraber> 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 <scott-work> sorry, work grabbed my attention, reading pastebin now
21:20:25 <Daviey> 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 <Daviey> cjwatson: good :)
21:20:41 <cjwatson> Daviey: it's the standard we've held other flavours to
21:20:48 <Daviey> ok
21:21:04 <cjwatson> it isn't a problem if flavours overachieve
21:21:16 <cjwatson> what we want to know is whether they can cope with the minimum requirements
21:21:23 <Daviey> Oh.
21:21:29 * Daviey relurks.
21:21:34 <stgraber> 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 <scott-work> i can address a few of the points already made when it is convenient
21:21:55 <cjwatson> absolutely, please go ahead
21:22:59 <scott-work> 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 <scott-work> themuso (luke) is active from time to time, but less and less honestly
21:23:48 <scott-work> 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 <scott-work> 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 <cjwatson> how do you plan to cope with doing security support for the range of packages specific to Ubuntu Studio?
21:24:38 <cjwatson> bearing in mind that less and less tends to come "for free" as the release ages
21:24:52 <scott-work> i would posit that most of the A/V specific packages are actually maintained in debian, however
21:25:04 <scott-work> i don't have hard data to back that up specifically
21:25:17 <scott-work> cjwatson: that isn't in response to your security question
21:26:23 <scott-work> 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 <cjwatson> 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 <micahg> cjwatson: sure
21:27:27 <cjwatson> thanks
21:28:22 <cjwatson> 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 <scott-work> cjwatson: i attempted that last LTS with ardour, i understand :)
21:29:33 <scott-work> "fumbling" with that might be a more apt description, though
21:29:47 <cjwatson> OK; can we follow up by mail, then?  Sorry again that this is a bit haphazard
21:30:05 <scott-work> i should also point out that ubuntu studio does now have it's own slide show installer
21:30:13 <cjwatson> 21:16 <cjwatson> (Ubuntu Studio doesn't have its own installer slideshow)
21:30:16 <cjwatson> :-)
21:30:19 <cjwatson> oh, wait
21:30:31 <cjwatson> "does now" probably not a typo for "does not", which is how I read it ...
21:30:49 <cjwatson> right, I see it now, sorry for the misinformation
21:32:50 <scott-work> hehe :)
21:32:50 <cjwatson> let's move on, then, and we'll get this firmed up by mail and return to it next time
21:33:14 <cjwatson> #topic Opening backports pre-release (redux)
21:33:16 <cjwatson> #link https://lists.ubuntu.com/archives/technical-board/2012-March/001224.html
21:33:41 <cjwatson> broder: I think this is to some extent a matter of you amending your own summary :-)
21:34:20 <cjwatson> 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 <broder> hmm, i see your point :)
21:34:53 <cjwatson> and what I'm hearing is that you intend to do (b) by way of re-uploadin
21:34:54 <cjwatson> g
21:35:19 <cjwatson> (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 <broder> 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 <broder> but if you read the history differently, i can run with that
21:37:03 <cjwatson> well I think (a) was simply a consequence of not re-uploading
21:38:52 <broder> 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 <cjwatson> OK, carried nem con then
21:40:46 <micahg> 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 <cjwatson> #topic AOB
21:40:49 <cjwatson> oh
21:40:57 <cjwatson> micahg: whoever uploaded them? :-)
21:41:11 <broder> micahg: you mean for backports?
21:41:15 <cjwatson> (hm, which indicates it can't be a bulk archive admin task)
21:41:45 <micahg> cjwatson: well, the rebuilds could be sponsored for the last person in the changelog, but that won't always be right
21:42:05 <broder> we could always lie in the changed-by line :)
21:42:27 <broder> "Uploaded to new dev release by Evan Broder on behalf of Micah\n\n -- Micah Gersten <etc>"
21:42:40 <cjwatson> I'm only really particularly bothered about somebody getting any build failure mails and being responsible for fixing those
21:42:51 <cjwatson> and for that, the signer of the package will get them
21:42:54 <cjwatson> if nothing else
21:43:03 <micahg> right
21:44:58 <micahg> 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 <cjwatson> well, it can't be the backport requestor, so I don't see who else is possible
21:46:23 <cjwatson> 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 <micahg> cjwatson: for regular backports it's fine, I'm speaking specifically of the pre-release uploads
21:46:55 <broder> 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 <broder> this seems analogous
21:47:01 <cjwatson> we could just make (fsvo) whoever did the pre-release upload do another one
21:47:11 <micahg> cjwatson: well, I'm speaking more of collateral damage in toolchain updates, not that it's broke per se
21:47:28 <cjwatson> 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 <broder> 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 <micahg> 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 <cjwatson> the TIL, the +1 maintenance team, package set owners, whoever happens to come along and get bothered by it ...
21:49:09 <cjwatson> 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 <micahg> sure, I'd just like it to be clear if there's such an expectation for responsibility
21:49:48 <micahg> not necessarily that we be able to hunt people down
21:49:56 <cjwatson> 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 <broder> 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 <cjwatson> 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 <cjwatson> *well
21:50:37 <cjwatson> that way the line of responsibility is obvious
21:50:43 <micahg> sounds good to me
21:51:20 <cjwatson> 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 <cjwatson> I expect that in many cases they'll be superseded by Debian syncs anyway
21:52:20 <cjwatson> any other business before we close?
21:52:36 <soren> The meeting or the agenda item?
21:53:09 <stgraber> both I guess (considering the current agenda item is AOB)
21:53:17 * stgraber doesn't have anything else
21:53:28 <soren> I guess we should talk about the meeting time again.
21:53:38 <soren> DST ends in the US this weekend, doesn't it?
21:53:46 <soren> And in Europe at the end of MArch.
21:53:55 <soren> Or am I a month too early?
21:53:58 * soren checks
21:54:15 <soren> Nope, that seems accurate.
21:54:20 <cjwatson> if somebody wants to organise another doodle or $better_tool, that would be awesome
21:54:33 <cjwatson> bagsy not it, as we used to say in primary school
21:54:44 <soren> And what did you mean? :)
21:54:51 <cjwatson> "<steps back>"
21:54:59 <soren> Ah :)
21:55:32 <soren> Well, March is special, isn't it?
21:56:01 <soren> For the next meeting, we'll be at an odd offset (Europe <-> US).
21:56:28 <stgraber> 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 <soren> stgraber: Just what I was trying to express as well. Thanks :)
21:57:02 <stgraber> (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 <soren> stgraber: Cool.
21:57:38 <stgraber> 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 <soren> Then we can do a Doodle for the first meeting after all of EUrope and US has gone DST.
21:58:02 <stgraber> sounds good
21:58:04 <cjwatson> stgraber: doesn't make much difference for me TBH
21:58:12 <cjwatson> don't know about pitti
21:58:25 <cjwatson> soren seems to cope?
21:58:39 <soren> Yeah, this is not too bad.
21:59:48 <soren> 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 <soren> So maybe this will be as simple as sticking with the current local time and just chaning the UTC time?
22:00:35 <soren> I'll send an e-mail to ask. We might not have to do the doodle at all. Yay.
22:00:59 <cjwatson> all right, thanks all
22:01:01 <cjwatson> #endmeeting