[03:28] <HFSPLUS> UBUNTU AND LINUX ARE CANCER IN A SENSE IF YOU USE IT YOUR BODY WILL GET SEPSIS AND YOU WILL GET CANCER EVERYWHERE IN YOUR BODY
[03:28] <HFSPLUS> !ops
[18:01] <robbiew> kees: meeting today?
[18:07] <mdeslaur> kees: meeting!
[18:07] <jdstrand> o/
[18:07] <jjohansen> \o
[18:08] <kees> \o
[18:08] <kees> sorry, lost in email backlog
[18:08] <nxvl> \o/
[18:08] <nxvl> kees: as all of us
[18:09] <kees> so, uhm, I drank a fair bit and then tried to push compiler hardening bits in Debian.  for this week, I'll take krb5 and continue to follow some of the community sponsorship requests.
[18:10] <robbiew> heh
[18:11] <mdeslaur> I'll take php5 and gimp, and will start the screenlocking debugging wiki page this week
[18:11] <kees> I'm still digging through backlog
[18:11] <mdeslaur> I'm on triage also
[18:11] <kees> mdeslaur: sorry about the state of bugs.  I managed to keep on top of CVE triage, though.  :P
[18:11] <mdeslaur> kees: np!
[18:12] <jdstrand> I plan to do some merges as well as some work on essential bps. I'll pick up an update if needed
[18:12] <jdstrand> s/if/as/
[18:13] <jdstrand> that's it from me
[18:13] <jdstrand> I suppose I could be slightly more specific
[18:14] <jdstrand> I hope to finish security-lucid-sponsorship-review
[18:14] <jdstrand> then look at apparmor stuff and the 0.7.5 libvirt merge
[18:14] <kees> jdstrand: for sponsorship processes, I have some questions now that I've followed it a few times.
[18:14] <jdstrand> then decide how to tackle the libvirt items
[18:15] <jdstrand> kees: ok
[18:16] <kees> if that's it on status, then I'll dive into my sponsorship questions?
[18:16] <jdstrand> kees: please do
[18:17] <kees> ok, so, following https://wiki.ubuntu.com/SecurityTeam/SponsorsQueue
[18:17] <kees> I had two hats: reviewer ("sponsor"?) and Uploader.
[18:17] <kees> first question is: at what point should the ubuntu-security-sponsors team be unsubscribed from a bug?
[18:18] <kees> (the only case seems to be when the patch needs work)
[18:19] <kees> should it be unsubbed when it's been uploaded?
[18:19] <jdstrand> kees: that is correct
[18:19] <jdstrand> though we will mark syncs as Invalid
[18:19] <jdstrand> and also Fix Released
[18:19] <kees> hrm
[18:19] <jdstrand> both of those drop the bug off the sponsors radar
[18:20] <jdstrand> kees: I started to do the whole separated process that I am sure you are thinking of
[18:20] <kees> ok, so Invalid and Fix Released, but ubuntu-security-sponsors stays sub'd.
[18:20] <jdstrand> kees: that is how it currently is, but ubuntu-security-sponsors could be unsub'd in those cases, but I don't see a real need for that
[18:21] <kees> ah! wait, I think I see the source of my confusion.
[18:21] <kees> the All open link will show bugs that are invalid when there are other open statuses for a bug.
[18:22] <kees> so, in the case of multiple releases, it gets confusing.
[18:22] <jdstrand> I didn't opt for the separated process because that is geared for larger teams-- in practice, we and motu-swat will be doing the reviewing-- so I kept it simple for now
[18:22] <nxvl> kees: as in New for Lucid and Invalid for Jaunty?
[18:22] <jdstrand> kees: that may be a bug in LP
[18:22] <kees> nxvl: right, or like bug 431080, where one part is In Progress (which doesn't need ubuntu-security-sponsors subbed) and others are fix released and invalid.
[18:23] <jdstrand> kees: I am writing a tool today, similar to pull-in-progress.py that will make it a bit easier to see
[18:23] <kees> hrm, why does 481631 still show up?
[18:23] <jdstrand> what needs work and the status of things
[18:24] <jdstrand> kees: probably because of the upstream bug?
[18:24] <kees> jdstrand: oh, no, the query is bad.  it includes Invalid and Won't Fix.
[18:24] <kees> I will adjust the wiki page.
[18:24] <jdstrand> ok, thanks
[18:25] <kees> alright.  that was basically it.  multiple confusions due to the LP bug list.  ;)
[18:26] <kees> oh yikes, moin just HTTP 500'd
[18:26] <jdstrand> kees: sorry about that
[18:26] <jdstrand> (not the 500-- I didn't have anything to do with that! ;)
[18:27] <kees> jdstrand: oh, I don't think that's your fault at all.  new processes are fun to clarify.  :)
[18:27] <kees> ok, so now following the "All open" link is much more sensible.
[18:27] <jdstrand> yeah-- hence the 'Beta Available' implementation :)
[18:27] <kees> do you think "In progress" should be removed from the list too, since that means the patch writer needs to work on it more?
[18:28] <jdstrand> kees: I don't, cause 'All' is supposed to convey all open bugs
[18:28] <kees> ok, sounds good.
[18:29] <jdstrand> plus, it also could mean that the bug has been uploaded to the ubuntu-security-proposed ppa, and needs to be pocket copied to -proposed
[18:29] <jdstrand> so I wouldn't want to hide it
[18:30] <jdstrand> (section '4.2 Uploads')
[18:30] <kees> ah! yes, just noticed that.
[18:31] <kees> ok, so, with bug 446838, what's the next step?
[18:31] <kees> we got a NACK on the hardy patch
[18:31] <kees> s/patch/package/
[18:31]  * jdstrand looks
[18:33] <jdstrand> kees: ok, so 'klumpen' said the patch doesn't work. that is not enough detail...
[18:34] <jdstrand> kees: ultimately though, this is in -proposed and for ubuntu-sru to handle using their processes
[18:34] <kees> that was my thought too.
[18:34] <jdstrand> kees: see '5. Verification'
[18:34] <kees> (I can do a verification for karmic, but not hardy)
[18:35] <jdstrand> kees: basically, once it goes from ubuntu-security-proposed to -proposed, ubuntu-sru takes it from there
[18:35] <kees> ok
[18:35] <jdstrand> that may sound somewhat contentious, but this won't happen for packages in main, and ScottK said that this is the process to use for universe
[18:36] <kees> it continues to show up on the "open" list, but I guess that's ok.
[18:36] <kees> regardless, I'm happy with the process.
[18:36] <jdstrand> kees: we could theoretically unsub ubuntu-security-sponsors at the point that ubuntu-sru has it, but I thought that since the processes are still being defined and people getting used to them, we should keep our eyes on the bug
[18:37] <jdstrand> s/defined/fine-tuned/
[18:37] <kees> yeah, and I think dholbach wants "finished" sponsorships to retain the sponsorship team for his reports.
[18:37] <ScottK> Sometimes pitti will push updates out if a particular release isn't tested if the risk seems low.
[18:37] <kees> ScottK: yeah, but do things get deleted from -proposed if someone NAKs?
[18:38] <ScottK> Generally the idea is they get superceded by a fixed update.
[18:38] <kees> okay
[18:38] <ScottK> They should, but I don't know that they always do.
[18:38] <kees> next up: http://piware.de/workitems/security/lucid/report.html
[18:38] <kees> that graph shouldn't include weekends and holidays.  ;)
[18:38] <jdstrand> I am pretty sure that if something doesn't supercede it, it will get deleted
[18:39] <jdstrand> it is a manual process of course
[18:39] <jdstrand> and I don't know how often that happens, but istr seeing it
[18:39] <jdstrand> kees: heh
[18:39] <kees> so, to keep us in line with the burndown, we need to either finish stuff or postpone stuff.
[18:40] <jdstrand> kees: well yes, but I thought we discussed that we weren't going to overly fret over the burndown-- has that changed?
[18:40] <kees> I already postponed all the "low", so I'm going to start fishing for "medium" stuff.
[18:40] <kees> jdstrand: I'm not going to fret at all -- the fact that we're postponing stuff directly reflects that we don't have time for some things.
[18:40] <jdstrand> (I remember the 'low' discussion)
[18:41] <kees> I think it's appropriate to choose that which gets tossed out.
[18:41] <jdstrand> ok
[18:41] <kees> and if we work from the lowest priority up, that reflects our committment to essential workitems.
[18:42] <jdstrand> keep in mind, I am doing dev work this week-- I hope to make some progress on my items :)
[18:42] <kees> to that end, I'd like us to run down the workitems assigned to people outside our team first, and then start picking stuff from our medium list to postpone.
[18:42] <kees> jdstrand: yup, that's great.  :)
[18:42] <kees> I'd like us to be in line by friday's review.
[18:43] <jdstrand> kees: well, with coffeedude, I'm not sure how much we can encourage it gets done. likewise is on their own timeframe. ttx may know more about it
[18:43] <kees> jdstrand: should we ping coffeedude.jerry?
[18:43] <kees> *one mind*
[18:43] <jdstrand> heh
[18:43] <kees> ok, cool.
[18:44] <jdstrand> next is jjohansen and 'clean up on pam_apparmor'
[18:44]  * kees nods
[18:44] <jdstrand> (also a 'medium')
[18:44] <kees> I already postponed kirkland's item.  :)
[18:44] <jjohansen> ah, yeah I have been meaning to get to that but not for alpha2
[18:45] <jjohansen> so yeah postpone please
[18:46] <kees> done
[18:46] <kees> ok, any questions for the security team or other items?
[18:46] <jdstrand> it seems that the parts of sbeattie's items are getting done... ie, the wiki is started
[18:46] <jdstrand> oh, they are postponed anyway. nm
[18:47] <kees> jdstrand: there's nothing wrong with flipping a postponed item to "done" too.  it's just a matter of tracking the line for a given moment in time.
[18:48] <jjohansen> yeah doesn't it then show up as green instead of yellow
[18:48]  * kees nods
[18:50] <kees> alrighty, meeting over.  thanks everyone!
[18:51] <robbiew> thanks kees!