[00:04] <mtaylor> thumper: ping
[00:05] <mtaylor> thumper: I have a feature request: ... just like a project can have a devel target branch, I think a project should also be able to have a devel target series and a devel target milestone
[00:06] <mtaylor> thumper: so that "file a bug against the current devel target series/milestone" and "target a blueprint to current devel target series/milestone" is really easy
[00:08] <mtaylor> I'm bringing this up because we're currently merging a lot of branches with no bug/blueprint associated with them in drizzle
[00:09] <mtaylor> but the number of steps I'd be asking someone to go through to add a blueprint aroud merge-request time is sort of redundant
[00:10] <mtaylor> what would be great is if an unadorned branch that  files a merge request could auto-create a blueprint with the merge-request summary as the blueprint description
[00:10] <mtaylor> and that is targetted to the current stuff - so that we've got a paper-trail of what was done without tons of extra dev work
[00:10] <mtaylor> thumper: I kept rambling ^^^
[00:12] <mtaylor> also - if there _is_ an associated blueprint, the blueprint desc could be used to pre-fill the merge request desc
[00:13] <mtaylor> sort of helping describe a relationship between blueprints and merge-requests
[00:33] <lifeless> mtaylor: it has all that
[00:33] <lifeless> mtaylor: devel target branch is modeled as 'branch of the devel series'
[00:34] <lifeless> mtaylor: but bug targeting (known as infestation) is underdeveloped - we had bad UI experiences in that space.
[00:34] <mtaylor> lifeless: well great then
[00:37] <mtaylor> lifeless: the "create merge-request from blueprint" or "create blueprint from merge-request" isn't there though, that would be a full-on feature request, yes?
[00:38] <lifeless> it would be a patch to do it.
[00:38] <lifeless> blueprints are unmaintained at the moment.
[00:39] <lifeless> some folk put in slack and weekend time on them
[00:39] <lifeless> but if there is something specific you want... :)
[00:49] <lifeless> mtaylor: oh, and I'd love to see people caring for this
[00:56]  * wgrant would love to see Blueprint put out of its misery.
[00:56] <lifeless> wgrant: one way or another ?
[00:56] <lifeless> wgrant: hey, while you're here, let me run something past you
[00:57] <wgrant> lifeless: Sure.
[00:57] <lifeless> wgrant: seems to me that the package management pages aren't really at home in the http://launchpad.net/* space, and might benefit from being in a dedicated domain like packages.launchpad.net/
[00:57] <lifeless> in the same way that code.* has a more focused UI
[00:57] <lifeless> (and bugs etc etc)
[00:58] <wgrant> lifeless: It's difficult, because packages are structural.
[00:58] <wgrant> Packages *have* bugs.
[00:58] <lifeless> not saying that the multi-domain approach is good or bad, just that the soyuz stuff is neither fish nor fowl at the moment, and there is some tension with the registry [metadata only, thanks] goal
[00:58] <lifeless> wgrant: so do branches ;)
[00:59] <wgrant> Branches are not bug targets.
[00:59] <wgrant> But yes, the Registry<-->Soyuz split is rather arbitrary, not done to well, problematic, and otherwise pretty terrible, both code and UI-wise.
[00:59] <lifeless> thats true
[00:59] <lifeless> wgrant: I would say that Package *names* have bugs
[01:00] <lifeless> wgrant: Binary and Source package instances do not.
[01:00] <lifeless> [infestation aside]
[01:01] <lifeless> wgrant: thanks for letting me run that past you ;)
[01:03] <wgrant> lifeless: That's true.
[01:03] <wgrant> But the lack of infestations is a bug.
[01:04] <lifeless> so there are two descrete concepts
[01:04] <lifeless> 'can have a bug'
[01:04] <lifeless> and 'can be a place that a bug fix should be done'
[01:04] <lifeless> package versions by there very nature are only able to satisfy the former.
[01:04] <lifeless> s/there/their/ blah.
[01:05] <lifeless> containers-of-packages can do both ('there is a package in this place with the bug', and 'we want to upload a new package here with a bugfix')
[01:05] <lifeless> under this model, I think there is a clear separation between registration stuff and package-instance stuff
[01:06] <lifeless> what do you think ?
[01:06] <wgrant> Indeed.
[01:06] <wgrant> What would go on the DistributionSourcePackage Registry page if the Soyuz one was split from it?
[01:07] <lifeless> so, like with other subdomains, a split doesn't mean 'do not reference', its about focus and primary presentation
[01:07] <wgrant> Right.
[01:07] <wgrant> But what would be the focus of the Registry page?
[01:07] <lifeless> I'd expect, on a DSP registry page to give primacy to controlling things like:
[01:07] <lifeless>  - acls
[01:08] <lifeless>  - policy [disable uploads of this package]
[01:08] <lifeless>  - history [of things we no longer keep as well as active package files]
[01:08] <lifeless>  - relationships to other packages
[01:08] <lifeless> Just riffing here at this point
[01:27] <thumper> mtaylor: hi, sorry, was out afk
[02:20] <mtaylor> lifeless: yes. I have put it on my todo list and plan on writing code in support of it
[02:20] <mtaylor> lifeless: which means step #1 - register a blueprint - will get done at some point :)
[02:22] <lifeless> mtaylor: given that LP doesn't really use blueprints for its own dev
[02:22] <lifeless> mtaylor: I don't think that that is step 1. Step 1 is 'propose a UI for it on the lp-dev list'
[02:22] <lifeless> discuss.
[02:22] <mtaylor> lifeless: ok.
[02:23] <mtaylor> lifeless: I imagine I may become the caretaker of all things blueprints...
[02:23] <mtaylor> lifeless: if there is not currently one, since we really like them ;)
[02:24] <lifeless> tag, you're it
[02:24] <lifeless> actually sinzui IIRC has spent considerable time on it
[02:24] <mtaylor> lifeless: awesome
[02:24] <lifeless> but all personal.
[02:25]  * mtaylor doesn't really want ownership - just expects to write some code
[02:25] <lifeless> so, start with that.
[02:25] <lifeless> Really.
[02:25] <lifeless> JFDI :)
[02:25] <mtaylor> yup
[02:25] <mtaylor> that's the idea
[02:25] <lifeless> step 0) get a working lp dev environment - have you got that ?
[02:25] <mtaylor> yup. step 0 done
[02:26] <lifeless> ok
[02:26] <lifeless> step 1) make a branch to work on this; have you got that ?
[02:26] <mtaylor> step 0.5 - complain about the number of steps needed for step 0
[02:26] <mtaylor> ;)
[02:26] <mtaylor> yup. step 1 done
[02:26] <lifeless> patches appreciate.
[02:26] <lifeless> step 2) if you are not sure where to start changing stuff, ask here.
[02:26] <mtaylor> lifeless: pushed onto stack
[02:27] <lifeless> remember that we like patches to be < 1000 lines, as a pretty hard limit, for the sanity of the reviewer.
[02:27] <lifeless> unless previously agreed.
[02:27] <mtaylor> yup. we're like that in drizzle
[02:27] <mtaylor> sequnces of self-contained small changes that don't break shit ftw
[02:27] <mtaylor> or sequences even
[02:29] <lifeless> mars: when does PQM open ?
[02:31] <thumper> it is supposed to be < 800
[02:31] <lifeless> oh, my bad.
[02:31] <thumper> PQM will open again when we have confirmed no massive fubar
[02:31] <thumper> lifeless: bigger can be done with prior agreement with a reviewer
[02:32] <lifeless> yeah - I mentioned that just above :P - but I had the # wrong.
[02:32] <thumper> lifeless: I just noticed that after I had written the line
[02:32] <thumper> :)
[02:32] <lifeless> lol
[02:33] <thumper> mtaylor: get yourself on the launchpad-dev mailing list :)
[02:34] <wgrant> The last comment on bug #474615
[02:34] <_mup_> Bug #474615: lp email 'rationale' header should use most specific criterion, or add header for direct subscription <story-better-bug-notification> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/474615>
[02:34] <wgrant> Why do people not file bugs about their broken mail providers?
[02:35] <thumper> wgrant: like gmail?
[02:35] <wgrant> How is it Launchpad's problem that some mail providers are crap?
[02:35] <wgrant> Right.
[02:35] <lifeless> well
[02:35] <thumper> I've filed a bug with gmail about not being able to filter on mail headers
[02:35] <lifeless> see, people *use* gmail. That we want to use lp.
[02:35] <lifeless> leverage.
[02:44] <lifeless> wgrant: so that bug, I don't think its really a gmail flaw per se. Yes headers are better. But its still simply nice to see the most proximate subscription - its the most relevant
[02:44] <lifeless> wgrant: did you mail the list about API privileges
[02:44] <lifeless> wgrant: if not, I can; I've been thinking on it.
[02:45] <wgrant> lifeless: I haven't really got time at the moment, I'm afraid.
[02:45] <lifeless> ok
[02:45] <lifeless> I'll carry your point forward and you can tell me how I do later
[02:46] <wgrant> Thanks.
[02:46] <lifeless> also, http://www.hemispheregames.com/osmos/ looks awesome, if totally offtopic here.
[02:46] <wgrant> It is awesome, yes.
[02:46] <wgrant> I discovered it a few months ago, just before the Linux port, but it still ran fine in Wine.
[02:52] <spm> hrm. no elves, no swords, no sharks with lasers?!?!? can't see the point.
[02:53] <lifeless> spm: addict.
[02:54] <spm> heh, perhaps.... :-)
[03:14] <poolie> lifeless: i was thinking of changing 'make run' to turn on tc slowness
[03:14] <poolie> perhaps with an escape hatch
[03:14] <thumper> heh
[03:14] <lifeless> mmm
[03:14] <lifeless> I think a target to start and stop tc would be awesome
[03:15] <lifeless> I don't know that there is a perception mismatch for most devs though.
[03:15] <lifeless> its tempting to think there is.
[03:15] <lifeless> what might be really fun is an incrementally slower 'make run'
[03:15] <lifeless> like, 1ms slower per second of runtime.
[03:16] <lifeless> :>
[03:17] <poolie> make slower
[03:17] <poolie> make faster
[03:17] <poolie> > not implemented yet
[03:17] <lifeless> lol
[03:18] <poolie> how do you mean incrementally slower?
[03:20] <lifeless> poolie: just that
[03:20] <lifeless> slower the longer its beein running
[03:20] <poolie> oh i see
[03:21] <poolie> it will add 1ms to the service time for each request?
[03:21] <lifeless> for instance yes
[04:22] <cody-somerville> Why would the milestone page show bugs as one status but viewing the actual bug show the bugs as a different status?
[04:22] <lifeless> its caching very aggressively now.
[04:22] <lifeless> Please file a bug
[04:23] <cody-somerville> Ok
[04:23] <wgrant> I filed a bug last week, but more dupes is good.
[04:26] <lifeless> well, please me-too it.
[08:10] <adeuring> good morning
[09:01] <mrevell> Morning!
[10:23] <mwhudson> morning
[10:32] <bigjools> morning
[11:43] <jml> is danilo around today?
[12:04] <deryck> Morning, all.
[12:12] <mrevell> jml, Danilo's on leave today
[12:12] <jml> mrevell, thanks.
[12:25] <mwhudson> jml: hello, how are you today?
[12:27] <jml> mwhudson, bowel-clenchingly busy. finishing slides for a talk I'm giving in < 3hrs
[12:27] <mwhudson> jml: oh right
[13:50] <jtv> wgrant: I'm trying to Q/A the launchpad-buildd changes...  do you know of a recipe that should build without problems?  When I try I get failures that I hear are probably unrelated: http://staging.launchpadlibrarian.net/51388616/buildlog.txt.gz
[14:08] <jtv> abentley, do you know of any recipes that definitely should build without problems on either staging or dogfood?  I'm trying to Q/A the latest launchpad-buildd so we can roll it out.
[14:10] <abentley> jtv, https://code.dogfood.launchpad.net/~abentley/+recipe/bazaar but you may need to change the debversion
[14:10] <jtv> henninge: any idea whether you'll be wanting those traits?
[14:11] <henninge> jtv: I think I do ... ;)
[14:12] <henninge> I mean, I'd like to have them.
[14:14] <wgrant> jtv: Any recipe build is going to fail like that, since staging doesn't seem to have Soyuz.
[14:14] <wgrant> Dogfood should work.
[14:23] <Ursinha> sinzui, hello, good morning
[14:24] <Ursinha> sinzui, something very weird is happening with the milestones of this project: https://edge.launchpad.net/iportfolio
[14:24] <Ursinha> I can't see them
[14:24] <Ursinha> maybe a typo lead to that?
[14:24] <Ursinha> s/1010/2010/
[14:25] <sinzui> I think someone put that date there
[14:25] <sinzui> users allowed to screw up
[14:25] <bigjools> wgrant: staging has builders, a buildd-manager and config.
[14:26] <wgrant> bigjools: But no archive.
[14:26] <sinzui> Ursinha, looks like you can create a date that the UI cannot support. The API does support it though
[14:26]  * sinzui reports bug
[14:26] <Ursinha> sinzui, hm, I see
[14:27] <bigjools> wgrant: you don't need an archive to test builds
[14:27] <wgrant> bigjools: You do if the primary archive's hostname is set to ftpmaster-staging.internal, and that doesn't exist.
[14:28] <bigjools> wgrant: that is being fixed (dunno who set that), then it will work
[14:28] <wgrant> Ah.
[17:55] <nettrot> Is there anyone from launchpad-foundations who can chat about Bug #602346?
[17:55] <_mup_> Bug #602346: Launchpad can save HTTP requests with DataURIs <Launchpad Foundations:Incomplete by foxxtrot> <https://launchpad.net/bugs/602346>
[19:58] <lifeless> any soyuz folk around ?
[20:01] <bigjools> lifeless: just about to grab a cold one and finish watching the footy, wassup?
[20:26] <lifeless> bigjools: hi
[20:26] <bigjools> too late I'm drunk
[20:26] <lifeless> bigjools: so the new private ppa private-owning-team change
[20:27] <lifeless> soren can see the owning team for the font ppa
[20:27] <lifeless> as in, see its main registry page.
[20:27] <bigjools> yeah we know
[20:27] <lifeless> Was this intentional ?
[20:27] <bigjools> sorta
[20:27] <lifeless> Do you have a bug saying you want to tune it more?
[20:27] <lifeless> Just so I can point surprised people at it :)
[20:27] <bigjools> I need to start a thread about this on the dev list, we just talked about it on the TL call
[20:28] <lifeless> sure
[20:28] <bigjools> no bug yet
[20:28] <lifeless> I'm only asking cause of soren's question on #launchpad
[20:28] <lifeless> :)
[20:28] <bigjools> we're talking about having a restrictedView permission
[20:28] <lifeless> in directory service terms
[20:28] <lifeless> what you want is 'traversal'
[20:28] <lifeless> as opposed to 'view'
[20:28] <bigjools> no, it's view
[20:28] <lifeless> really ?
[20:28] <bigjools> partial view of a private object
[20:29] <lifeless> what bits ?
[20:29] <bigjools> the name of the private team is needed to form it's PPA URL for example
[20:29] <bigjools> its*
[20:29] <bigjools> gah hate that mistake
[20:29] <lifeless> (actually, if you're drunk, and this is known, you can stay drunk and watch the sport :))
[20:29] <lifeless> bigjools: I'd say that traversal implies accessing the metadata needed to present anything got at by traversing.
[20:30] <bigjools> from a zope PoV, yeah
[20:31] <bigjools> lifeless: I'm open to suggestions, thumper had some concerns about dealing with a new permission
[20:31] <bigjools> but I'm going back to the  footy now :)
[20:31] <bigjools> ciao
[20:32] <lifeless> bigjools: EPIC stuff.
[20:53] <bigjools> lifeless: yes
[20:58] <thumper> morning
[20:58] <lifeless> morning thumper
[21:54] <lifeless> wgrant: lp:~leonardr/launchpad/grant-permissions-oauth :P
[21:54] <lifeless> wgrant: someone used a time machine, I think.
[21:55] <leonardr> wgrant, lifeless, what's up?
[21:55] <lifeless> wgrant: its not quite what is needed, but its close
[21:55] <lifeless> leonardr: hey! so you've done something that is very very close to what didrocks' gpg/ssh management stuff needs.
[21:55] <lifeless> leonardr: which is a API way to manage security sensitive stuff
[21:56] <leonardr> lifeless: ok, what do you need beyond what's in that branch (and its implied follow-ups)?
[21:56] <lifeless> I don't know yet.
[21:57] <lifeless> but its in the space
[21:57] <lifeless> did you see the thread on lp-dev, and the LEP ?
[21:57] <leonardr> no, i'm looking now
[21:57] <lifeless> there is a missing bit which is 'perhaps we shouldn't let *every* API client change gpg/ssh keys, even though email notifications is a great safety net'
[21:57] <lifeless> wgrant raised this and I think his points are valid, so we should try to slot something nice into the use case.
[21:58] <lifeless> perhaps your tool should manage ssh and gpg keys on lp too
[21:58] <lifeless> rather than quickly doing it
[21:58] <leonardr> lifeless: given the way GRANT_PERMISSIONS can be used for privilege escalation, it might make more sense to have a separate access level
[21:58] <leonardr> and a separate app
[21:59] <leonardr> however, the credential manager could administer the granting of this new access level to this separate app
[21:59] <lifeless> leonardr: if you'd like to throw some thoughts into the ring, that would be lovely
[21:59] <lifeless> its a little time sensitive (isn't it always)
[21:59] <leonardr> sure
[22:00] <leonardr> from what i've heard here, it sounds like splitting out WRITE_SECURITY_SENSITIVE from WRITE_PRIVATE would work
[22:00] <lifeless> if you have a preference as well, please indicate that too
[22:01] <lifeless> I think didrocks is really able to tell us best what will work out well in the structure and what may be an issue
[22:01] <leonardr> lifeless, can you give me a subject line and/or link to a web archive? my mail skills are notoriously bad
[22:01] <leonardr> and i can't find this thread
[22:02] <lifeless> [Launchpad-dev] Fwd: [Fwd: Quickly and Launchpad]
[22:02] <leonardr> thanks, i had no idea what quickly was
[22:03] <lifeless> its a mini IDE kind of thing
[22:03] <lifeless> puts program boilerplate together
[22:03] <lifeless> builds debs of python programs
[22:03] <leonardr> cool. i'll write a response
[22:03] <lifeless> sets up a development environment
[22:03] <lifeless> thanks!
[22:09] <leonardr> lifeless: if i understand the problem correctly, it's the danger of a malicious app making up a fake ssh key and uploading it?
[22:10] <lifeless> or a new gpg key
[22:10] <lifeless> I think you can add a key for an address you haven't validated previously, and it mails that address automatically
[22:10] <lifeless> which the user wouldn't see
[22:11] <lifeless> new gpg key would allow exposure of private branch content (but then WRITE_PRIVATE has that anyway)
[22:11] <lifeless> sorry
[22:11] <lifeless> new ssh key would ...
[22:11] <lifeless> new gpg key would allow uploading packages
[22:11] <lifeless> that the user hadn't signed, and its currently got more of a security shell around it
[22:12] <lifeless> probably the whole set of interactions needs consideration
[22:12] <lifeless> I'm not 100% sure wgrant is right in saying we need to do something about this - but I think we have to at least *think* critically about it
[22:13] <leonardr> all right
[22:18] <james_w> congratulations lifeless
[22:31] <thumper> lifeless: congrats
[22:34]  * bigjools hi-fives lifeless
[23:08] <nettrot> I'm noticing that some of the JS Tests in Launchpad are in YUI Test, others are in Windmill. Is there a preference for new tests? And/or what is the reason for the two frameworks?
[23:15] <thumper> nettrot: Windmill came first