[07:43] <Speedy2> www.search2.net
[07:44] <elky> Is that a typo or are you spamming us?
[07:44] <vish> elky: spam
[07:44] <elky> it does appear that now
[07:45] <vish> elky: i'v just reported it to the ops, its been happening in several channels
[07:46] <elky> Yeah, i noted. I was going to see if they were a human who could be reasoned with.
[07:49] <dholbach> good morning
[18:00] <mdeslaur> jdstrand, kees: meeting?
[18:01] <kees> mdeslaur: ah, yes.  it's that time, isn't it?
[18:01] <kees> jdstrand: ready?
[18:01] <mdeslaur> kees: my calendar thinks it is :)
[18:01] <jdstrand> o/
[18:01] <kees> :)
[18:01] <jdstrand> yes
[18:01] <kees> okidoky
[18:01] <kees> this week, OOo publication, and then going to check for any low-hanging fruit
[18:02] <persia> If there's time in the agenda, can I grumble a bit about community integration at the end?
[18:02] <kees> I'd like to finish some of the qrt stuff I had on my plate (like the additional RNG tests)
[18:02] <kees> persia: totally
[18:02] <mdeslaur> persia: yes
[18:02] <persia> THanks.
[18:02] <kees> probably going to start another kernel update cycle soon too
[18:03] <kees> looks like we made feature freeze pretty well.
[18:03] <kees> that's it from me.  mdeslaur, you're up.
[18:03] <mdeslaur> I just published pidgin updates. I plan on attacking the new squid issue, and the ffmpeg updates next.
[18:04] <mdeslaur> besides that, I'm on community, so have been going down the sponsoring list
[18:04] <mdeslaur> that's pretty much it
[18:04]  * jjohansen fades in late
[18:04] <jdstrand> so I guess I'm up next
[18:05] <jdstrand> I am triager this week
[18:06] <jdstrand> I plan to talk to soren walk me through kvm-autotest to see how we can use it in QRT for our gui applications. it should be totally doable
[18:06] <kees> oooh, I was just thinking about that today in the shower -- I wanted to see if I could build an OOo test
[18:06] <jdstrand> kees: exactly (though for me it was firefox)
[18:07] <kees> I worry about use having different resolutions, languages, installed applications in our VMs, though.
[18:07] <mdeslaur> wouldn't Mago be more appropriate for that?
[18:07] <jdstrand> I looked at it a it on my own last week, but it was not...
[18:07] <jdstrand> obvious...
[18:07] <kees> yeah
[18:07] <jdstrand> how to use it in that capacity
[18:07] <jdstrand> soren gave that presentation at the sprint and seems to think it shouldn't be a problem-- so I'm hopeful :)
[18:08] <persia> Mago requires accessibility support.  kvm-autotest requires reliable display parameters (which kvm can provide).
[18:08] <jdstrand> mdeslaur: I looked at Mago a bit, but didn't find documentation on how to really get into it
[18:08] <jdstrand> plus what persia mentioned
[18:08]  * robbiew sneaks in the back door :/
[18:09] <mdeslaur> I'm just kind of afraid with kvm-autotest that it will be hard to always have a 100% reproducable environment
[18:09] <jdstrand> I plan to see what is next on the 'what CVE to fix next' list, and do that
[18:09] <jdstrand> mdeslaur: I think we can with snapshots, etc
[18:10] <jdstrand> mdeslaur: anyway, I'm investigating right now, not integrating :)
[18:10] <mdeslaur> ok, fair enough :)
[18:10] <mdeslaur> jdstrand: don't forget, I run my VMs at 1920x1080
[18:10] <jdstrand> mdeslaur: if you have some good resources for mago, I'd like them too
[18:10] <kees> jdstrand: if you start getting somewhere with it, let me know and I can "reproduce locally"  :)
[18:10] <kees> mdeslaur: seriously?
[18:10] <mdeslaur> kees: no
[18:10] <kees> hah
[18:11] <jdstrand> mdeslaur: well, I take you point. these would likely have to be 'special' VMs anyway (ie, kvm-autotest and libvirt doesn't make sense afaict)
[18:11] <mdeslaur> oh, okay
[18:11] <jdstrand> but anyway, we'll see-- I just thought there might be something there, and soren is willing to walk me through it
[18:12]  * kees hopes to re-use the libvirt-configured VMs
[18:12] <mdeslaur> jdstrand: don't forget to bug soren as much as possible while he's still on the payroll :)
[18:12] <jdstrand> kees: me too... we'll see
[18:13] <jdstrand> I might be able to wrap stuff, etc, like I did with vm-tools. but like I said, I've barely looked at it :)
[18:13] <jdstrand> anyhoo
[18:14] <jdstrand> if I have time, I'd like to see if I can clean up the apparmor abstractions, esp for firefox/evince
[18:14] <jdstrand> that's it for duties. I do have two items to bring up-- one is I'm fairly sure related to what persia wants to talk about
[18:14] <jdstrand> persia: why don't you go ahead?
[18:15] <persia> Probably :)
[18:15] <persia> OK.  jdstrand and I have been having a productive conversation in a thread at https://lists.ubuntu.com/archives/ubuntu-motu/2010-February/006550.html
[18:15] <persia> Summarised, the TB and DMB have approved a proposal that significantly limits the scope of "MOTU".
[18:16] <persia> So, since "MOTU" no longer maps well to "community supported", I'd like to see some initiative from the wider security team (potentially including current members of MOTU SWAT) to define a process that supports the entire archive wihout relying on the scope of MOTU.
[18:19] <kees> sounds good to me.
[18:19] <jdstrand> that makes sense to me, but, tbh, it is clear to me how "community supported" is being defined in the new world. I guess "not in officially supported" is one definition, but there then is a team surrounding "not officially supported"
[18:19] <jdstrand> err
[18:19] <jdstrand> s/is/isn't/
[18:19]  * persia much prefers "not supported by Canonical" to "not officially supported", but yes, this needs thought.
[18:19] <jdstrand> fair enough
[18:19] <kees> we'll have the help of the Supported: tag in the packages files
[18:20] <persia> It's going to be a bit before everything is implemented, so there's time, but it seems appropriate to start thinking about it now so that we don't get caught later.
[18:20] <jdstrand> yeah, that defines our responsibilities
[18:20] <mdeslaur> persia: Is there anything you see that would need changing in our current process?
[18:21]  * kees mumbles something about syncSource ACLs in LP
[18:21] <jdstrand> persia: also, not pointing fingers or being judgemental, but motu-swat has not been active for a while. the reasons are numerous and in part due to lack of process from ubuntu-security (which should all be fixed now)
[18:21] <persia> mdeslaur: Were I designing the process, and noting that my understanding of your process is entirely based on jdstrand7s email, I'd probably only do the following:
[18:21] <kees> no amount of our process can reduce the bottleneck that is LP's lack of ACLs, though.
[18:22] <persia> 1) declare an inclusive security group with responsibility for everything (although some members may concentrate in certain areas).
[18:22] <kees> but, outside of that, I'd agree: we've tuned the process to eliminate human bottlenecks as much as possible
[18:22] <persia> 2) encourage all members of that group to actively review and sponsor stuff.
[18:22] <jdstrand> kees: yes, but if more people submitted patches and more people joined ubuntu-security-sponsors, I think we could handle the publishing bits ok
[18:22] <persia> 3) have a restricted set that is responsible for pocket copies and USN releases.
[18:22] <jdstrand> (I'd love to see the volume of community supported patches be a real problem for us)
[18:23] <persia> I think that's mostly a matter of making sure submitters feel entitled as part of the team.
[18:23] <mdeslaur> persia: this is the team that has responsibility of reviewing everything: https://launchpad.net/~ubuntu-security-sponsors
[18:23] <persia> I know that when we do stuff in MOTU that involves telling people that submitting patches makes them Ubuntu Developers, we get more patches.
[18:23] <kees> persia: 3 exists, 2's element of "encourage" hasn't happened, though we've asked the community team for help there. 1 exists as ubuntu-security-sponsors, IIUC
[18:24] <persia> kees: I think you're right, and that it's just a matter of semantics and communication.
[18:24] <jdstrand> well, the ubuntu-security team itself is how it is due to ACLs and requiring the possibility for embargoed issues.
[18:24] <jdstrand> it could I guess be a subteam in this whole thing...
[18:25] <jdstrand> kees: your understanding is correct on '1'
[18:25] <kees> persia: our problem has traditionally been that of motivating others; we're usually utterly slammed for time, and doing coaching, blogging, etc can be very time-consuming.
[18:25] <jdstrand> keep in mind, that the new process for sponsoring security uploads is just that: new this cycle. I personally wanted to see how it worked for a little bit to make sure it was sane
[18:26] <jdstrand> however, we are fully integrated into the MOTU pages now-- from dholbach's reports, to Sponsoring pages to how you can help
[18:26] <persia> I understand entirely :)  I just wanted to raise the point, because while I think all the process stuff jdstrand mentioned in the email was good, I found some of the phrasing and language exclusive, and based on previous meeting logs, though it was pervasive in the sematics of the team, rather than being jdstrand's email.
[18:26] <jdstrand> the only thing that wasn't done was an email to ubuntu-motu@ and ubuntu-devel@
[18:27] <mdeslaur> persia: right now, we always have one team member who is on active community-sponsoring duty, so if a bug is opened and a debdiff submitted, it will get reviewed and uploaded in a few days.
[18:27] <persia> mdeslaur: Right.  I think that's great.  I just want to highlight that there are likely to be other groups than MOTU active in universe, and that this probably has implications related to the semantics of your communications.
[18:29] <jdstrand> persia: there is a difference between canonical supported and community supported, and a necessary exclusivity in some ways-- it is our team's job to take care of canonical supported pacakges. our name is on the USN, it is in the emails to bugtraq, etc. in some ways, submitting a debdiff for a package in main is a lot like just giving us a VCS link to a fix
[18:29] <jdstrand> persia: that said, I don't want to appear as exclusive
[18:29] <persia> Heh.
[18:30] <persia> I understand the difficulty, and don't want to complicate things :)
[18:30] <jdstrand> that didn't come out quite right
[18:30] <jdstrand> I want people involved, but there is very much a difference between a community supported package and a canonical supported, from our point of view
[18:30] <persia> There are differences between the set of things that is done related to embargoes and USNs and pocket copies.
[18:30] <jdstrand> I'm not sure that matters though-- there is so much to do in community supported packages that just isn't happening now
[18:31] <persia> I'm less confident there's a meaningful difference between "main" and "universe" for stuff that isn't embargoed.
[18:31] <persia> (because any dev can upload it)
[18:31] <kees> there is -- it's an SRU
[18:31] <jdstrand> persia: are we talking about stable releases or devel?
[18:31] <kees> so, when something goes into main, we're responsible for it.
[18:31] <persia> Don't you do both?
[18:31] <jdstrand> persia: stable and devel? yes
[18:32] <jdstrand> persia: but we are directly responsible for main/restricted
[18:32] <jdstrand> for stable
[18:32] <jdstrand> in fact, a supported configuration is running an Ubuntu system with -security but without -updates
[18:33] <persia> Right.  I think we havea  close to common understanding of stuff.
[18:33] <persia> I agree there needs to be a distinction for certain folks active in security.
[18:33] <jdstrand> sure-- I think it is perhaps a matter of perspective, and my language is tainted by my perspective
[18:34] <persia> I just think there needs to be a distro-wide security team of some sort (which may well be ubuntu-security-sponsors) that is highlighted as a central team, rather than relying on each developer team to grow it's own security folk.
[18:34] <persia> Mine too :)
[18:34] <kees> I'm actually not convinced that's the right thing to do.
[18:34] <kees> I think each developer team needs to know how to handle stable security updates.
[18:35] <kees> they're much more familiar with the code and how to test
[18:35] <persia> OK.  How do we deal with security for stuff not handled by the restricted set of security developers then?
[18:35] <kees> I'm not saying we shouldn't have a general security team, but I don't think we should discourage security work by devel teams
[18:35] <persia> can we convince each team to grow a security representative?  Or would we do better to have a central coordnation team that reached out when CVEs were published?
[18:36] <persia> Just as a semantic note: I consider teams to be massively overlapped, so I'd hope that individual developers might participate in several teams.
[18:36] <kees> I think each team should at least have a security representative -- perhaps the same person that deals with SRUs.
[18:36] <jdstrand> kees: I was not trying to discourage anyone, and would hope that people from the dev teams would provide patches for their stuff (with testing)
[18:37] <kees> jdstrand: right, i was replying persia's "rather than relying on each developer team to grow it's own security folk."
[18:37] <persia> OK.  This could work.  In that case, there *should* be a MOTU swat, but each developer team should also havea  similar body.
[18:37] <jdstrand> ah
[18:37] <kees> since I *do* want devteams to grow security folk
[18:38] <kees> persia: I think that would be ideal, yes.  however, we've had a very hard time growing either type of person.  :)
[18:38] <persia> I don't think we need to continue having a hard time :)
[18:38] <persia> Just petition the tech board to add a requirement that devteams nominate some -security and -updates contacts.
[18:38] <jdstrand> the devel release is often much more exciting than a stable release for most people
[18:39] <kees> persia: how would that be tracked in LP/
[18:39] <persia> And that those contacts are expected to participate in discussions with the central -updates and -security teams (so they'd be at this meeting).
[18:39] <kees> s#/#?#
[18:39] <persia> kees: Nominees would be added to ubuntu-security-sponsors and fill roles similar to that of motu swat today.
[18:40] <kees> I'm looking for a way for an outsider to answer the question "who is the security contact for [team]?" when looking at LP.
[18:40] <jdstrand> persia: so anyone could provide the debdiff (including the devteam) and then the rep from the devteam in ubuntu-security-sponsors could ack it
[18:40] <jdstrand> ?
[18:41] <persia> kees: A wiki page?
[18:41] <persia> jdstrand: And with luck the security rep from the devteam helps in other ways, but yes.
[18:41] <kees> persia: okay, seems disconnected from LP a bit, but it's the best we've got.
[18:41] <persia> kees: The other alternative is to have special teams like ubuntu-desktop-security, but I don't think that scales.
[18:41] <kees> the issue is finding someone that can help with testing.  no one likes testing ancient stable releases.  :(
[18:42] <persia> LP needs to get smarter before we have that feature.
[18:42] <persia> That's why you get the TB to require devteams to nominate someone :)
[18:42] <jdstrand> yeah, last stable is about as far back as people like to test
[18:42] <kees> I want to avoid this person from becoming a bottleneck, though, and I worry that might become socially tricky.
[18:43] <kees> "You never checked with me about this patch!"   "You weren't online."  etc
[18:43] <jdstrand> I can imagine an ack on a patch, but waiting on testing
[18:43] <persia> kees: Could we work around that by a combination of "Ubuntu doesn't have maintainers" and allowing a devteam to nominate several members rather than one if coordination may be an issue?
[18:43] <jdstrand> kees: I think that should be solved be our sponsorship process
[18:44] <jdstrand> (it, ACKs, etc in LP)
[18:44] <kees> I guess my entire opinion is best summarized by "I would love more people participating, but since that number is approaching zero, I see no reason to impose groups/lists/etc"
[18:44] <persia> Fair.  I'm just concerned about the packages that are no longer cared for by MOTU slipping through the cracks.
[18:45] <mdeslaur> kees: I agree with that...once we actually _get_ debdiffs we can start looking how to increase sponsoring, etc.
[18:45] <kees> wel, to be honest, they already are slipping through the cracks.
[18:45] <persia> OK, maybe I'm approaching this from the wrong direction then.
[18:45] <persia> (and feel free to change topic if time is short)
[18:45] <kees> stefanlsd and jstrand helped a great deal to close the crack with the sync-finder and sync-doer, though
[18:46] <persia> Perhaps we ought think about "How do we extend the security process to more actively encourage patch submissions from devteams to the security team?"
[18:46] <jdstrand> persia: that is the question
[18:46] <kees> but, I mean, the list is huge even after that: http://people.canonical.com/~ubuntu-security/cve/universe.html
[18:47] <persia> As long as we answer that question in a way that works with Archive Reorg, all my concerns about MOTU SWAT are resolved.
[18:47] <jdstrand> persia: that is what we tried to do with our recent procedural changes (so it isn't a wholly new process)
[18:47] <kees> persia: right, I like that.  I like _anything_ that'll get more people helping.
[18:47] <persia> OK.  So, I suggest that explicity expecting devteams to actively track at least open CVEs in their packagesets is a place to start.
[18:48] <persia> Until MOTU's responsibility gets smaller, I'm unsure MOTU SWAT can keep up, but it sets a model that means that as new devteams are formed, they are already participating in the process.
[18:48] <james_w> integration with harvest could be a good idea
[18:48] <persia> That also skips the requirement for specific nominees, etc. (although if you add a request to report in this meeting, a natural nominee will likely emerge)
[18:50] <kees> persia: yeah, I do like the idea of solidifying "expecting devteams to actively track at least open CVEs in their packagesets"
[18:51] <jdstrand> I'm not sure what that will get us, but we'll see
[18:51] <persia> kees: And would you be willing to add "expecting devteams to report on the progress of such tracking during the weekly security team meeting"?
[18:51] <kees> persia: sure, I guess that would be good.
[18:52] <persia> Well, that combination matches my preferred mental model well enough that I'm completely satisfied :)
[18:52] <kees> persia: where should these suggested idea be presented?  TB or DMB?
[18:52] <kees> I assume TB
[18:53] <persia> TB: it'S the TB that is responsible for approving devteams.  The DMB only approves membership changes in devteams if so delegated.
[18:53]  * kees nods
[18:53] <persia> jdstrand: did you have anything else on this, or shall we move to the second of your "two things"?
[18:54] <jdstrand> persia: I'm pretty much of the same mind as everyone-- more involvement is good. how we get there is rather secondary to me
[18:55] <kees> persia: I've added this to the TB agenda now: https://wiki.ubuntu.com/TechnicalBoardAgenda
[18:55] <jdstrand> simply put, I don't have anything else
[18:55] <persia> kees: Excellent :)
[18:55] <kees> jdstrand: oh, I thought you had a second item, non-overlapping with persia?
[18:56] <jdstrand> kees: I do, I was letting go of persia's sleeve is all
[18:56] <kees> hah, ok
[18:56] <jdstrand> the other thing is a bit of a clarification on security support in -backports
[18:56] <jdstrand> specifically bug #411849
[18:57] <jdstrand> my understanding was that it is up to the backports team to do this type of thing
[18:57] <kees> I agree 100%
[18:58] <jdstrand> alright, so, so I guess that is it on that then
[18:58] <jdstrand> ubuntu-security got dragged into that bug and it seemed at least worth reviewing
[18:58] <kees> jdstrand: yeah, backports is not our problem in the least, IMO.
[18:59] <jdstrand> I agree (and responded as such in the bug)
[18:59] <kees> if anyone feels differently, I'm all ears, but my operating principle has been to ignore -backports totally.
[18:59] <kees> okay, cool
[19:00] <kees> anyone have anything else?
[19:00] <mdeslaur> not me
[19:00] <kees> thanks everyone!
[19:01] <jdstrand> o
[19:01] <jdstrand> o/