[12:40] <mas999> Hiiii
[12:40] <mas999> no one?
[18:02] <jdstrand> o/
[18:02]  * sbeattie waves hello
[18:02] <jdstrand> #startmeeting
[18:02] <meetingology> Meeting started Mon Mar  5 18:02:29 2012 UTC.  The chair is jdstrand. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[18:02] <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
[18:02] <jdstrand> [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting
[18:02] <jjohansen> \o
[18:02] <micahg> o/
[18:03] <jdstrand> [TOPIC] Announcements
[18:03] <jdstrand> * Thanks
[18:03] <jdstrand> Kilian Krause (kilian) from Debian provided debdiffs for lucid for fex (DSAs 2414 and 2259)
[18:03] <jdstrand> Your work is very much appreciated and will keep Ubuntu users secure. Great job! :)
[18:03] <jdstrand> [TOPIC] Review of any previous action items
[18:03] <jdstrand> ACTION: sbeattie to follow up on qrt bugs from QA team
[18:04] <sbeattie> Yep, did that (finally)
[18:04] <jdstrand> \o/
[18:04] <jdstrand> sbeattie: thanks :)
[18:05] <jdstrand> [TOPIC] Weekly stand-up report
[18:05] <jdstrand> I'll go first
[18:05] <jdstrand> I finally got caught up on archive admin work
[18:05] <jdstrand> I'm in the happy place this week and hope to catch up on MIR security audits
[18:06] <jdstrand> there is an embargoed issue I am working on
[18:06] <jdstrand> and maybe I can pick back up some pending updates
[18:06] <jdstrand> if not by the end of the week, certainly next week
[18:06] <jdstrand> (assuming nothing else comes up)
[18:07] <jdstrand> mdeslaur: you're next
[18:07] <mdeslaur> I'm on triage this week
[18:07] <mdeslaur> I released lightdm updates this morning, and am currently testing flashplugin-nonfree
[18:07] <mdeslaur> and then I have an embargoed issue I'm working on
[18:08] <mdeslaur> I have a few security bugs to research
[18:08] <mdeslaur> and then will pick other updates from the list
[18:08] <mdeslaur> that's it from me
[18:08] <mdeslaur> sbeattie: you're it
[18:08] <sbeattie> I'm in the happy place this week
[18:09] <sbeattie> I'm still working on my glibc update
[18:09] <sbeattie> Once that's done, I'll be focusing on apparmor userspace bugs/workitems
[18:10] <sbeattie> that's pretty much it for me.
[18:10] <sbeattie> is micahg back?
[18:10] <micahg> yes
[18:12] <jdstrand> micahg: it's your turn
[18:12] <micahg> I uploaded chromium earlier this morning and will be testing that, still trying to get the Firefox/icedtea crash fixed (now with new upstream commit :)), and time permitting webkit, this is also the week before Mozilla's rapid release day, so I'll be staging and testing anything that's available this week
[18:12] <micahg> jdstrand: I know, just a little slow typing :)
[18:12] <micahg> that's it for me I think, tyhicks?
[18:13] <tyhicks> I'm handling community this week
[18:13] <jdstrand> micahg: let me test chromium when it goes to -proposed again.
[18:13] <micahg> jdstrand: as you wish
[18:14] <tyhicks> I will start on a gnutls update
[18:14] <tyhicks> and work on an embargoed issue
[18:14] <tyhicks> that's it for me
[18:14] <tyhicks> jjohansen?
[18:15] <jjohansen> well, I need to post out the revisions to the upstream kernel patches
[18:15] <jjohansen> and debug some mount failures, that people are running into
[18:16] <jjohansen> I am testing the fix to minimization, and we should be able to get that uploaded today too
[18:16] <jjohansen> other than that /me wants to try picking off his remaining work items this week
[18:17] <jjohansen> thats it for me I think jdstrand back to you
[18:17] <jdstrand> thanks
[18:18] <jdstrand> micahg: I meant to ask: how is the webkit progress?
[18:19] <micahg> well, if I can spend a little bit of time on it, I should be able to start uploading some test builds to my PPA this week
[18:19] <jdstrand> awesome!
[18:19]  * jdstrand hopes the chromium testing helps there
[18:19] <jdstrand> [TOPIC] Highlighted packages
[18:19] <jdstrand> The Ubuntu Security team will highlight some community-supported packages that might be good candidates for updating and or triaging. If you would like to help Ubuntu and not sure where to start, this is a great way to do so.
[18:20] <jdstrand> See https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures for details and if you have any questions, feel free to ask in #ubuntu-security. To find out other ways of helping out, please see https://wiki.ubuntu.com/SecurityTeam/GettingInvolved.
[18:20] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/slim.html
[18:20] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/icecast2.html
[18:20] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/libdigest-perl.html
[18:20] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/xfce4-session.html
[18:20] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/djbdns.html
[18:20] <jdstrand> [TOPIC] Miscellaneous and Questions
[18:20] <jdstrand> we do have one topic to discuss:
[18:20] <jdstrand> * Discuss another non-native PPA for staging SRUs and development packages
[18:21] <jdstrand> this came up as a result of internal discussions
[18:21] <mdeslaur> non-native?
[18:21] <jdstrand> the basic idea is this-- we have PPAs for our security updates, but not our dev work
[18:21] <jdstrand> actually, s/non-native//
[18:21] <jdstrand> no decisions are made (sorry)
[18:22] <jdstrand> would it be helpful to have a team ppa that we all have enabled, for the dev release or SRUs
[18:22] <jdstrand> we wouldn't have any mandatory process around it at this time
[18:23] <jdstrand> but, for example, if sbeattie was preparing an apparmor userspace upload, or jjohansen a kernel upload, or me a ufw upload and we wanted others from the team to test it, we upload there
[18:23] <jdstrand> and then everyone just gets it automatically
[18:23] <jdstrand> is it worthwhile?
[18:24] <tyhicks> jdstrand: This ppa would only be enabled on our machines that we do not use for security update testing, right?
[18:24] <jdstrand> tyhicks: yes. this is for dev work, not security updates
[18:24] <jjohansen> is it any better than having a separate ppa for each project?
[18:24] <jdstrand> tyhicks: ie, you might upload ecryptfs there
[18:24] <jdstrand> jjohansen: it is only better in that it is a one stop for all our dev work
[18:24] <tyhicks> gotcha
[18:25] <jdstrand> ie, we decide we all run with that ppa enable
[18:25] <jdstrand> enabled
[18:25] <jdstrand> as opposed to having 7 different ppas enabled
[18:25] <jdstrand> (or whatever)
[18:25] <jjohansen> hrmm, down side is you can't be selective about which ppa you have enabled
[18:26] <jdstrand> I don't have a staging ppa for ufw anyway, so I think it could help with that sort of thing too
[18:26] <mdeslaur> jdstrand: this isn't for experimental stuff, right? this is for "I'm ready to upload, but want some more testing first"?
[18:26] <jdstrand> jjohansen: this is meant to be for fairly stable stuff-- we don't want to break our teammates machines. we can always do that in other ppas
[18:26] <mdeslaur> ie: you wouldn't push apparmor dbus stuff in there
[18:26] <jdstrand> mdeslaur: correct
[18:27] <jdstrand> the idea is this is a 'testing' ppa for what is eventually going to hit the archive
[18:27] <tyhicks> experimental ppa'
[18:27] <jdstrand> whether it be the dev release or an SRU (I imagine this is less useful for SRUs since we typically run the dev release)
[18:27] <tyhicks> oops... experimental ppa's would be the daily build ppa's
[18:27] <jdstrand> tyhicks: yes, or soemthing else
[18:28] <jdstrand> again, this should be fairly stable
[18:28] <tyhicks> yep
[18:28] <sbeattie> jdstrand: well, some of us do have stable release machines around as well
[18:28]  * jdstrand nods
[18:28]  * sbeattie looks askance at his build server
[18:29]  * sbeattie is not sure he's got security-proposed enabled everywhere it could be.
[18:29] <sbeattie> generally, I'm in favor of this; I do think it should probably be a seperate ppa from security-proposed.
[18:29] <jdstrand> so, this isn't meant to be an administrative burden. it is meant to allow us to more easily and test the stuff we are uploading
[18:30] <mdeslaur> sbeattie: you do know I upload completely untested stuff to security-proposed, right? :)
[18:30] <micahg> as do I :)
[18:30] <jdstrand> eg, my 2.8beta1 apparmor upload might have gone there
[18:30] <sbeattie> mdeslaur, micahg: and that's different from the stuff going into devel how? :-)
[18:30] <jdstrand> (it was something I did test and run, but might have been nice to have others run it for a bit before uploading to the archive proper)
[18:31] <jdstrand> I really wanted to test jjohansen's recent kernel-- this could have been something we all could have just gotten 'for free'
[18:31] <tyhicks> jdstrand: It makes sense to me. Instead of everyone being affected by a new bug, it would result in potentially just our team being affected. We would have been affected anyways, if we didn't have this buffer ppa to catch it early.
[18:31] <jdstrand> tyhicks: yes
[18:32] <jjohansen> jdstrand: uh kernel builds from ppas are an absolute pita
[18:32] <tyhicks> If we have systems that are a bit too critical for something like this, we just don't enable it on those systems.
[18:32] <mdeslaur> yeah, the kernel is probably a bad example there
[18:32] <jdstrand> I am not advocating this running everywhere
[18:33] <jdstrand> I am only advocating is use for the dev release. we can use it for SRUs if people want. the stuff we upload should be solid in our minds, not experimental :)
[18:33] <jdstrand> re kernel> not sure why, we use to build them all the time in our ppa, but whatever. let's not get hung up on that detail
[18:34] <jdstrand> in other words> whatever machine you are running the dev release on, just enable this ppa too
[18:34] <jdstrand> (not necessarily testing VMs)
[18:35] <jdstrand> do we agree that it could be worthwhile? if we don't like it, we don't need to continue using it
[18:35] <tyhicks> I don't see any negatives. I would have gotten the update on my development release machines either way.
[18:36] <sbeattie> jdstrand: +1 from me.
[18:36] <tyhicks> The only possible negative is that it adds a bit of a delay to the update receiving testing from a wider audience, but I don't consider that a big issue
[18:36] <tyhicks> jdstrand: +1 from me
[18:36] <jdstrand> mdeslaur, micahg, jjohansen: ^
[18:36]  * micahg wonders if jdstrand wants to cast an official vote :)
[18:36] <mdeslaur> I'm indifferent to the idea, 0 from me
[18:37]  * jjohansen is indifferent too
[18:37] <jdstrand> tyhicks: well, keep in mind, we aren't defining process for using it now. if we need a quick upload, we can always do that straight to the archive still
[18:37] <jdstrand> +1
[18:37] <jdstrand> ok, then let's try it
[18:37] <micahg> +1
[18:38] <jdstrand> I know sbeattie and mdeslaur don't want it to be ubuntu-security-proposed. I really don't care, but if not ubuntu-security-proposed, what do you want to name it?
[18:38] <jdstrand> micahg: heh, I thought you voted already :)
[18:38] <sbeattie> ubuntu-security-testing?
[18:38] <micahg> ubuntu-security-devel
[18:38] <tyhicks> seems like dev/devel should be in there somewhere
[18:38] <sbeattie> mmm, yeah, that's probably better
[18:38] <micahg> ubuntu-security-devel-testing
[18:39] <mdeslaur> this will have -updates enabled so we can also put SRU stuff in there?
[18:39] <jdstrand> mdeslaur expressed a desire to use it for SRUs
[18:39] <jdstrand> (even though he cast a '0' today :)
[18:39] <sbeattie> ubuntu-security-devel-testing-this-will-eat-your-filesytem-or-brain
[18:39] <mdeslaur> jdstrand: watch it or I'll switch to -1 :)
[18:39] <jdstrand> sbeattie: it better not! :P
[18:39] <micahg> mdeslaur: makes sense as we have security-proposed for non-updates enabled, also there's the option to copy from security-proposed to this for wider testing as well
[18:39] <jdstrand> mdeslaur: we have enough votes already :P
[18:40] <jdstrand> updates should be enabled. these aren't security updates
[18:40] <mdeslaur> cool
[18:40] <jdstrand> ubuntu-security-staging?
[18:41] <tyhicks> I have no problem with that
[18:41] <mdeslaur> sure
[18:42]  * sbeattie is also okay with -staging
[18:43] <jdstrand> ok. cool. let's skip the native vs non-native bit for when its actually seen some usage
[18:44] <mdeslaur> sure
[18:44] <jdstrand> Does anyone have any other questions or items to discuss?
[18:44] <jdstrand> oh
[18:44] <mdeslaur> I've got a question for tyhicks
[18:44] <tyhicks> mdeslaur: shoot
[18:45] <jdstrand> [ACTION] jdstrand to setup ubuntu-security-staging ppa and communicate to team
[18:45] <meetingology> ACTION: jdstrand to setup ubuntu-security-staging ppa and communicate to team
[18:45] <mdeslaur> tyhicks: what's the status on #842647? It's unclear to me
[18:45] <tyhicks> mdeslaur: I tried off and on for several days to reproduce it and no longer can (despite being able to reproduce it in the past)
[18:46] <tyhicks> mdeslaur: So, I went ahead and wrote up a patch over the weekend
[18:46] <mdeslaur> tyhicks: could you update the bug please in the next few days so everyone knows what's up with it?
[18:46] <tyhicks> mdeslaur: Yep, my plan is to do it today. I was up in the air while working on it over the weekend.
[18:47] <tyhicks> do it == update the bug
[18:47] <mdeslaur> tyhicks: ok, cool...sorry :)
[18:47] <tyhicks> I deserve the questioning since I didn't get my activity report in :)
[18:47] <mdeslaur> ehe
[18:48] <mdeslaur> jdstrand: sorry, back to you
[18:49] <jdstrand> I don't have anything else
[18:49] <jdstrand> Does anyone have any other questions or items to discuss?
[18:52] <jdstrand> mdeslaur, sbeattie, micahg, tyhicks, jjohansen: thanks! :)
[18:52] <jdstrand> #endmeeting
[18:52] <meetingology> Meeting ended Mon Mar  5 18:52:26 2012 UTC.
[18:52] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-03-05-18.02.moin.txt
[18:52] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-03-05-18.02.html
[18:52] <mdeslaur> thanks jdstrand!
[18:52] <tyhicks> thanks!
[18:52] <micahg> thanks jdstrand
[18:52] <sbeattie> jdstrand: thanks!
[18:52] <jjohansen> thanks jdstrand
[20:59] <cjwatson> kees,soren,stgraber: TB?
[20:59]  * cjwatson pokes mdz and pitti on -devel
[21:00] <soren> o/
[21:00]  * stgraber waves
[21:01] <cjwatson> that's four; the minutes of the last meeting say kees was to chair, but I guess I can do it seeing as I was supposed to chair last time round
[21:02] <cjwatson> #startmeeting
[21:02] <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] <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] <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] <cjwatson> but I only skimmed the logs very quickly just before this meeting; can somebody confirm?
[21:03] <stgraber> correct
[21:03] <stgraber> and the ARB chose to maintain a single source package for each set of lens+scopes
[21:03] <stgraber> so no policy change is required
[21:04] <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] <cjwatson> #topic agenda detangling
[21:05] <cjwatson> AFAICS what the agenda *should* consist of is the Ubuntu Studio LTS item
[21:05] <cjwatson> to which there've been no followups on the list thus far
[21:06] <cjwatson> anyone want to dispute or amend that agenda?
[21:06] <broder> i have a quick backports related questoin that i just sent mail about if you guys don't mind looking quickly
[21:07] <mdz> cjwatson, no dispute
[21:08] <soren> ditto
[21:08] <cjwatson> broder: OK, I've appended that
[21:08] <cjwatson> wiki is now resembling accurate
[21:08] <cjwatson> #topic Ubuntu Studio LTS Plan Proposal
[21:08] <cjwatson> #link https://lists.ubuntu.com/archives/technical-board/2012-February/001214.html
[21:08] <cjwatson> Scott Lavender is usually scott-work, but does not appear to be here
[21:09]  * stgraber digs for his germinate script, trying to get a unique list of source packages for ubuntu studio
[21:10] <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] <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] <stgraber> I'm also a bit worried about getting this LTS application so late in the cycle
[21:12] <soren> That doesn't really worry me, tbh.
[21:13] <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] <cjwatson> personally I'd like to have a clear idea of which developers are active
[21:13] <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] <cjwatson> scott-work has generally referred to himself as an organiser rather than a developer, IME
[21:15] <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] <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] <cjwatson> (Ubuntu Studio doesn't have its own installer slideshow)
[21:16] <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] <mdz> cjwatson, I have nothing to add
[21:16] <cjwatson> I'm happy to collate comments from here and respond
[21:17] <cjwatson> they have a lot of AV packages that aren't elsewhere, but that's kind of the point of Ubuntu Studio
[21:17] <cjwatson> aha
[21:17] <stgraber> hey scott-work
[21:17] <scott-work> hello :)
[21:17] <cjwatson> thanks for showing up at short notice; sorry we weren't organised about the agenda in advancec
[21:18] <cjwatson> I'll /msg you the discussion so far
[21:18] <Daviey> stgraber: Hang on, are you suggesting that only the packagesets will be in the pool at 5 years?
[21:18] <stgraber> scott-work: http://paste.ubuntu.com/870519/ is what we've said so far
[21:18] <stgraber> oh, apparently cjwatson was faster ;)
[21:18] <cjwatson> ah, I'll stop then :-)
[21:18] <cjwatson> no, I was just getting started
[21:19] <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] <cjwatson> Daviey: we have no mechanism to trim the pool that way, and no plans to implement such a mechanism :)
[21:20] <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] <scott-work> sorry, work grabbed my attention, reading pastebin now
[21:20] <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] <Daviey> cjwatson: good :)
[21:20] <cjwatson> Daviey: it's the standard we've held other flavours to
[21:20] <Daviey> ok
[21:21] <cjwatson> it isn't a problem if flavours overachieve
[21:21] <cjwatson> what we want to know is whether they can cope with the minimum requirements
[21:21] <Daviey> Oh.
[21:21]  * Daviey relurks.
[21:21] <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] <scott-work> i can address a few of the points already made when it is convenient
[21:21] <cjwatson> absolutely, please go ahead
[21:22] <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] <scott-work> themuso (luke) is active from time to time, but less and less honestly
[21:23] <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] <scott-work> and as such i would presume to be the key contact
[21:24]  * micahg won't commit to fixing stuff for Ubuntu Studio for the LTS, but is happy to help sponsor stuff for them
[21:24] <cjwatson> how do you plan to cope with doing security support for the range of packages specific to Ubuntu Studio?
[21:24] <cjwatson> bearing in mind that less and less tends to come "for free" as the release ages
[21:24] <scott-work> i would posit that most of the A/V specific packages are actually maintained in debian, however
[21:25] <scott-work> i don't have hard data to back that up specifically
[21:25] <scott-work> cjwatson: that isn't in response to your security question
[21:26] <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] <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] <micahg> cjwatson: sure
[21:27] <cjwatson> thanks
[21:28] <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] <scott-work> cjwatson: i attempted that last LTS with ardour, i understand :)
[21:29] <scott-work> "fumbling" with that might be a more apt description, though
[21:29] <cjwatson> OK; can we follow up by mail, then?  Sorry again that this is a bit haphazard
[21:30] <scott-work> i should also point out that ubuntu studio does now have it's own slide show installer
[21:30] <cjwatson> 21:16 <cjwatson> (Ubuntu Studio doesn't have its own installer slideshow)
[21:30] <cjwatson> :-)
[21:30] <cjwatson> oh, wait
[21:30] <cjwatson> "does now" probably not a typo for "does not", which is how I read it ...
[21:30] <cjwatson> right, I see it now, sorry for the misinformation
[21:32] <scott-work> hehe :)
[21:32] <cjwatson> let's move on, then, and we'll get this firmed up by mail and return to it next time
[21:33] <cjwatson> #topic Opening backports pre-release (redux)
[21:33] <cjwatson> #link https://lists.ubuntu.com/archives/technical-board/2012-March/001224.html
[21:33] <cjwatson> broder: I think this is to some extent a matter of you amending your own summary :-)
[21:34] <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] <broder> hmm, i see your point :)
[21:34] <cjwatson> and what I'm hearing is that you intend to do (b) by way of re-uploadin
[21:34] <cjwatson> g
[21:35] <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] <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] <broder> but if you read the history differently, i can run with that
[21:37] <cjwatson> well I think (a) was simply a consequence of not re-uploading
[21:38] <broder> ok. in that case i'll withdraw my request for clarification and move forward without turning on component isolation
[21:38]  * cjwatson waits to see if anyone disagrees with this interpretation
[21:39]  * stgraber agrees
[21:40]  * soren too
[21:40] <cjwatson> OK, carried nem con then
[21:40] <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] <cjwatson> #topic AOB
[21:40] <cjwatson> oh
[21:40] <cjwatson> micahg: whoever uploaded them? :-)
[21:41] <broder> micahg: you mean for backports?
[21:41] <cjwatson> (hm, which indicates it can't be a bulk archive admin task)
[21:41] <micahg> cjwatson: well, the rebuilds could be sponsored for the last person in the changelog, but that won't always be right
[21:42] <broder> we could always lie in the changed-by line :)
[21:42] <broder> "Uploaded to new dev release by Evan Broder on behalf of Micah\n\n -- Micah Gersten <etc>"
[21:42] <cjwatson> I'm only really particularly bothered about somebody getting any build failure mails and being responsible for fixing those
[21:42] <cjwatson> and for that, the signer of the package will get them
[21:42] <cjwatson> if nothing else
[21:43] <micahg> right
[21:44] <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] <cjwatson> well, it can't be the backport requestor, so I don't see who else is possible
[21:46] <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] <micahg> cjwatson: for regular backports it's fine, I'm speaking specifically of the pre-release uploads
[21:46] <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] <broder> this seems analogous
[21:47] <cjwatson> we could just make (fsvo) whoever did the pre-release upload do another one
[21:47] <micahg> cjwatson: well, I'm speaking more of collateral damage in toolchain updates, not that it's broke per se
[21:47] <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] <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] <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] <cjwatson> the TIL, the +1 maintenance team, package set owners, whoever happens to come along and get bothered by it ...
[21:49] <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] <micahg> sure, I'd just like it to be clear if there's such an expectation for responsibility
[21:49] <micahg> not necessarily that we be able to hunt people down
[21:49] <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] <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] <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] <cjwatson> *well
[21:50] <cjwatson> that way the line of responsibility is obvious
[21:50] <micahg> sounds good to me
[21:51] <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] <cjwatson> I expect that in many cases they'll be superseded by Debian syncs anyway
[21:52] <cjwatson> any other business before we close?
[21:52] <soren> The meeting or the agenda item?
[21:53] <stgraber> both I guess (considering the current agenda item is AOB)
[21:53]  * stgraber doesn't have anything else
[21:53] <soren> I guess we should talk about the meeting time again.
[21:53] <soren> DST ends in the US this weekend, doesn't it?
[21:53] <soren> And in Europe at the end of MArch.
[21:53] <soren> Or am I a month too early?
[21:53]  * soren checks
[21:54] <soren> Nope, that seems accurate.
[21:54] <cjwatson> if somebody wants to organise another doodle or $better_tool, that would be awesome
[21:54] <cjwatson> bagsy not it, as we used to say in primary school
[21:54] <soren> And what did you mean? :)
[21:54] <cjwatson> "<steps back>"
[21:54] <soren> Ah :)
[21:55] <soren> Well, March is special, isn't it?
[21:56] <soren> For the next meeting, we'll be at an odd offset (Europe <-> US).
[21:56] <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] <soren> stgraber: Just what I was trying to express as well. Thanks :)
[21:57] <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] <soren> stgraber: Cool.
[21:57] <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] <soren> Then we can do a Doodle for the first meeting after all of EUrope and US has gone DST.
[21:58] <stgraber> sounds good
[21:58] <cjwatson> stgraber: doesn't make much difference for me TBH
[21:58] <cjwatson> don't know about pitti
[21:58] <cjwatson> soren seems to cope?
[21:58] <soren> Yeah, this is not too bad.
[21:59] <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] <soren> So maybe this will be as simple as sticking with the current local time and just chaning the UTC time?
[22:00] <soren> I'll send an e-mail to ask. We might not have to do the doodle at all. Yay.
[22:00] <cjwatson> all right, thanks all
[22:01] <cjwatson> #endmeeting
[22:01] <meetingology> Meeting ended Mon Mar  5 22:01:01 2012 UTC.
[22:01] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-03-05-21.02.moin.txt
[22:01] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-03-05-21.02.html
[22:01] <soren> #action Soren to send an e-mail to the mailing list to confirm that we'll stick to the current time..
[22:01] <soren> Oh, too late..
[22:01] <soren> :)
[22:01] <cjwatson> whoops.  but noted :)