[00:21] <maxb> Urgh
[00:21] <maxb> bzr-tarmacland breaks 'bzr selftest'
[00:30] <poolie> maxb, as in, it has failing tests, or it breaks it entirely?
[00:30] <lifeless> popping into supermarket back in a bit
[00:52] <maxb> as in, it has code in its tests that failed to import, so the entire execution dies
[01:29] <wgrant> thumper: Are you looking at the buildbot failure too?
[01:29] <wgrant> It is legit, for once.
[01:29] <thumper> I wasn't
[01:29]  * wgrant does.
[01:39] <thumper> gah, my landing failed due to the non [testfix] nature
[01:39]  * thumper leaves the devel fix to wgrant
[01:40] <thumper> wgrant: is it obvious?
[01:42] <wgrant> thumper: Yes.
[01:42] <wgrant> thumper: Just running the Bugs tests now.
[01:43] <wgrant> (the test suite was clearly not run over the problematic branch :/)
[02:05] <bryceh> running rocketfuel-get just now it fails in mailman:
[02:05] <bryceh> Compiling /home/bryce/launchpad/lp-branches/devel/lib/mailman/Mailman/i18n.py ...
[02:05] <bryceh> Compiling /home/bryce/launchpad/lp-branches/devel/lib/mailman/Mailman/versions.py ...
[02:05] <bryceh> make[1]: Leaving directory `/home/bryce/launchpad/lp-sourcedeps/sourcecode/mailman'
[02:05] <bryceh> make: *** [compile] Error 2
[02:05] <bryceh> make: Leaving directory `/home/bryce/launchpad/lp-branches/devel'
[02:06] <lifeless> yup
[02:06] <lifeless> use lucid
[02:06] <lifeless> or fiddle with stuff under the hood as per sinzui's bug about this
[02:06] <bryceh> $ grep CODENAME /etc/lsb-release
[02:06] <bryceh> DISTRIB_CODENAME=lucid
[02:06] <bryceh> bug #?
[02:08] <lifeless> interesting
[02:08] <lifeless> hmm, possibly we've broken mailman on lucid by fixing for natty><
[02:08] <lifeless> sinzui: ^
[02:09] <StevenK> So we're aiming for Lucid, Maverick and Natty?
[02:10] <lifeless> we deploy on lucid.
[02:11] <lifeless> its mandatory until a new LTS is ready
[02:11] <lifeless> everything else I don't particularly care about :)
[02:31] <spm> ARGH!
[02:31] <spm> who made the change that makes it impossible to suspend a user without forcibly resetting their password?
[02:31]  * spm grumps
[02:32] <thumper> spm: not me
[02:33] <wgrant> spm: Wha? LP doesn't have passwords.
[02:34] <spm> fiik. wouldn't let me suspend them unless I set their password as well.
[02:34] <spm>  +reviewaccount fwiw. has password fields now
[02:35] <spm> click the 'change' button and get a "No! Password not set! bad Losa!" error message.
[02:36] <lifeless> file a bug
[02:37] <spm> nearly completed. I was ranting here so the bug won't be quite so vitrolic.
[02:37] <spm> :-)
[02:37] <lifeless> [02:37] <lifeless>     Hard / Soft  Page ID
[02:37] <lifeless>      150 / 5403  Archive:+index
[02:37] <lifeless>       98 /  385  BugTask:+index
[02:37] <lifeless>       97 /  126  Archive:EntryResource:getPublishedBinaries
[02:37] <lifeless>       37 /  332  Distribution:+bugs
[02:38] <lifeless>       29 /  134  ProjectGroupSet:CollectionResource:#project_groups
[02:38] <lifeless>       20 /   33  MailingListApplication:MailingListAPIView
[02:38] <lifeless>       13 /    8  ProjectGroup:+milestones
[02:38] <lifeless>       10 /   13  DistroSeriesLanguage:+index
[02:38] <lifeless>        9 /  307  Distribution:+bugtarget-portlet-bugfilters-stats
[02:38] <lifeless>        7 /   14  NullBugTask:+index
[02:44] <spm> thumper: do we have any juju to remove comments from merge proposals?
[02:44] <thumper> spm: no
[02:44] <thumper> spm: just sql
[02:44] <thumper> spm: just another of the reasons we should have a singular comment interface
[02:45] <thumper> (which we don't have)
[02:45] <spm> I don't spose you have that handy?
[02:45] <spm> heh
[02:45] <thumper> spm: sorry, no
[02:45] <thumper> spm: the table is codereviewcomment
[02:45]  * spm files another bug ;-)
[02:49] <lifeless> thumper: it is pretty much a single thing in the data model; what do you see as needed to propogate it higher?
[02:49] <thumper> bugs handle comments differently
[02:49] <spm> so do answers fwiw
[02:49] <thumper> lifeless: bugs store the initial description as the first comment (which is hidden in the UI)
[02:50] <thumper> lifeless: there are also bug specific fields on the message table
[02:50] <thumper> lifeless: and the comments pretend to be email messages
[02:50] <wgrant> And don't even start thinking about attachments...
[02:50] <thumper> which they aren't always
[02:50] <lifeless> thumper: there are? I thought those fields were in BugMessage
[02:50] <thumper> I seem to recall some specific bug thing
[02:50] <thumper> perhaps it is gone now
[02:51] <thumper> but the underlying model is quite different
[02:51] <thumper> and should be normalised
[02:51] <thumper> and extracted from the message table
[02:51] <thumper> which is a pile of poo
[02:51] <thumper> wgrant: how are those tests going?
[02:52] <lifeless> thumper: what would that leave behind? why isn't it just s/message/comment/ (and thus not very interesting)
[02:53] <thumper> lifeless: the incoming email processor stores all emails directly in the message / messagechunk tables
[02:53] <thumper> as well as the librarian
[02:53] <thumper> it is not a good model for comments
[02:53] <thumper> the message table doesn't store the text
[02:53] <thumper> there are one or more message chunks that do that
[02:53] <thumper> it is just overly messy
[02:53] <lifeless> yes, thats done to handle ginormous comments
[02:54] <thumper> well, I don't have the original raisins
[02:54] <lifeless> it lets us sequence comments without having to deal with a very fat table
[02:54] <lifeless> so its faster
[02:57] <wgrant> thumper: Sorry, got distracted with payroll stuff. I'm pretty sure they try to make it as awkward and unintuitive as possible.
[02:57]  * wgrant creates an MP.
[03:02] <thumper> wgrant: if it is a testfix, rs=me
[03:03] <wgrant> thumper: https://code.launchpad.net/~wgrant/launchpad/makeBug-testfix/+merge/45200
[03:05] <thumper> wgrant: done
[03:06] <wgrant> thumper: Thanks.
[03:55] <lifeless> poolie: around?
[04:04] <poolie> lifeless, hi
[04:04] <lifeless> poolie: call ?
[04:16] <poolie> lifeless, hi,  now?
[04:19] <lifeless> https://dev.launchpad.net/BugTriage
[04:23] <lifeless> https://bugs.launchpad.net/launchpad-project/+bugs
[06:03] <lifeless> wgrant: hey
[06:03] <lifeless> stub: hi
[06:04] <stub> yo
[06:04] <lifeless> archive:+index is getting worse daily
[06:04] <lifeless> any chance you can drill in a bit to get some faster way to answer the questions it needs to ?
[06:05] <wgrant> dogfood sort of fails to be terribly useful at analysing this sort of query.
[06:05] <wgrant> Because dogfood is awful.
[06:05] <lifeless> it succeeds at being terrible
[06:07] <stub> I'm supposed to be dealing with the test suite leaving garbage db's around, which I guess I should bump in favor of the timeouts.
[06:08] <lifeless> ah
[06:08] <stub> Do we have any real slow queries, including the ids in the IN clauses?
[06:08] <lifeless> only the 500ms ones
[06:08] <lifeless> (which is pretty slow given the amount of data they are returning)
[06:09] <lifeless> stub: well, I can't speak for your priorities right now :) - but to me the test suite stuff is important, but unblocking other developers is more important [for you specifically]
[06:09] <lifeless> I don't know if gary would agree
[06:10] <stub> I can try to reproduce slow queries using random ids in the IN clause, but genuine data will work better.
[06:11] <wgrant> I can try to find some genuine data.
[06:11] <lifeless> wgrant: are you able to generate a representative ready-to-run query ?
[06:11] <lifeless> jinx!
[06:11] <wgrant> Not sure how valid it will be, given that DF is from October.
[06:11] <wgrant> But we'll see.
[06:11] <lifeless> wgrant: perhaps a template query and a couple of queries to run on prod to populate data like archive ids etc
[06:12] <lifeless> ok, I need to run for a while to organise dinner
[06:15] <stub> wgrant: I can run a query on production to generate the list of ids if that helps
[06:16] <wgrant> stub: Thanks. I'll work one out soonish.
[06:31] <al-maisan> Good morning !
[06:32] <wgrant> Morning al-maisan.
[06:55] <lifeless> bryceh: fwiw bug 697441
[06:55] <_mup_> Bug #697441: buildmailman fails under python 2.7 (natty) <python-upgrade> <Launchpad itself:Triaged> < https://launchpad.net/bugs/697441 >
[07:24] <stub> wgrant: When we are doing those 400-1000ms queries with the SourcepackagePublishingHistory.id IN (...) clauses, do we already have the SourcepackagePublishingHistory objects available? I suspect we don't need to actually join with that (big) table in most cases.
[07:26] <wgrant> stub: We should have them. But that should be fairly cheap regardless, right?
[07:27] <lifeless> I'm curious what an explain analyze says is up
[07:27] <stub> Its a big table, and unnecessary joins constrain the planner. And I usually consider 100ms 'fairly cheap', so yes :)
[07:33] <stub> wgrant: Do you know what the BuildFarmJob.status codes we are selecting for?
[07:33] <wgrant> stub: Let me see if I can remember which method it is.
[07:38] <stub> lifeless: http://paste.ubuntu.com/550516/ with random ids and buildfarmjob.status IN (1,2)   (both statuses are fairly large categories)
[07:41] <lifeless> so its having to generate temp datasets
[07:42] <lifeless> both of which are being built and sorted rather than delivered from indices
[07:44] <lifeless> it also looks to be highly correlated
[07:45] <lifeless> stub: are both halves of the union equally expensive?
[07:48] <stub> lifeless: roughly
[07:50] <stub> Unfortunately I can't easily benchmark the variant that eliminates the two unnecessary ORDER BY and SourcePackagePublishingHistory joins, as I end up with about 6 subqueries that make it go slower.
[07:50] <lifeless> hmm
[07:50] <lifeless> I see 193 and 749 now that I look closely
[07:50] <lifeless> so the >< side is the one to focus on
[07:53] <stub> Where do you see that? I see 1067 and 908
[07:54] <stub> Oh... actual time. I'm using estimated time. Actual time will be affected because rows will already be in RAM
[07:55] <lifeless> welll. run it twice ;)
[07:56] <lifeless> we've seen mismatches between estimate and actual that matter before, haven't we?
[08:05] <stub> Interesting Gnome lockup...
[08:05] <stub> Anyway...
[08:06] <stub> just removing the two unnecessary ORDER BY statements in the subqueries seems to half the runtime by itself. Removing the SourcePackagePublishingHistory table from the joins should be a decent win too.
[08:35] <adeuring> good morning
[08:58] <mrevell> Morning
[11:04] <mpt> Would any kindly Launchpad developer be able to give me a list of the top, say, 50 Launchpad projects by number of blueprints they have?
[11:14] <wgrant> mpt: https://pastebin.canonical.com/41512/, but it's a couple of months out of date.
[11:14] <mpt> wgrant, brilliant, thanks.
[12:02] <deryck> Morning, all.
[12:32] <wgrant> mpt: Are we?
[12:33] <mpt> wgrant, are we what?
[12:33] <wgrant> mpt: Starting to contact the projects that most use blueprints.
[12:33] <mpt> wgrant, ah, yes, I just talked with mrevell about it
[12:34] <wgrant> Excellent, excellent news.
[12:40] <leonardr> gmb, i seem to be using an ec2test image that doesn't have the python-lxml dependency you added around dec. 23
[12:40] <leonardr> do you know how that could be happening?
[12:41] <wgrant> Is the branch you're running utilities/ec2 from reasonably up-to-date?
[12:41] <leonardr> wgrant: i think so, but maybe not
[12:41] <leonardr> i'm updating now
[12:41] <leonardr> hopefully that'll fix it
[12:41] <wgrant> The test run will merge devel before it starts, but you need a recent version locally to have the image whitelisted.
[12:45] <leonardr> thanks, i'm guessing that was the problem
[12:45] <leonardr> trying again now
[12:46] <leonardr> "using machine image version 504"
[12:46] <wgrant> Looks good.
[14:59] <bac> abentley, adeuring, allenap , bac, benji, danilo, sinzui, deryck, EdwinGrubbs, flacoste, gary, gmb, henninge, jelmer, jcsackett, jtv, bigjools, leonard, mars, mrevell: Reviewer meeting ping
[14:59] <gary_poster> thanks
[14:59] <deryck> yes, thanks
[14:59] <adeuring> bac: thanks for the reminder!
[15:00] <gmb> Ta
[15:20] <jcsackett> henninge: ping.
[15:20] <henninge> Hi jcsackett!
[15:21] <jcsackett> hi henninge. is recife still undergoing qa?
[15:21] <henninge> jcsackett: yup
[15:21] <jcsackett> do you know when it might be done? i'd like to be able to be sure it will make release. :-)
[15:22] <henninge> jcsackett: I plan to finish tomorrow around this time. I don't expect any problems atm.
[15:23] <jcsackett> henninge: that sounds excellent. can you let me know if you run into any hurdles or if there's any way i can help out?
[15:23] <henninge> jcsackett: sure, I will
[15:23] <henninge> thanks for offering! ;)
[15:23] <jcsackett> :-)
[15:23] <jcsackett> thanks, henninge.
[15:52] <flacoste> Edwin-afk, sinzui: how is QA of bug 682727 coming along?
[15:52] <_mup_> Bug #682727: obsolete-junk/+series times out when the user is not anonymous <lp-registry> <qa-needstesting> <timeout> <Launchpad itself:Fix Committed by edwin-grubbs> < https://launchpad.net/bugs/682727 >
[15:52] <flacoste> jcsackett: can you QA bug 589584?
[15:52] <_mup_> Bug #589584: merge proposal status is clickable but doesn't show hand cursor <ajax> <bugjam2010> <confusing-ui> <lp-code> <qa-needstesting> <trivial> <Launchpad itself:Fix Committed by jcsackett> < https://launchpad.net/bugs/589584 >
[15:53] <EdwinGrubbs>  flacoste: it's done, I just marked it now.
[15:53] <flacoste> thanks EdwinGrubbs!
[15:53] <jcsackett> flacoste: qaing it now.
[15:58] <jcsackett> flacoste: i'm having to hunt down another problem--the branch merge proposal page is OOPSing on qastaging on opening diffs, which isn't something i've modified.
[15:58] <jcsackett> at least, i don't believe it is, and don't see the behavior on launchpad.dev with that branch.
[16:00] <flacoste> jcsackett: you might ask abentley for help with that problem
[16:00] <jcsackett> flacoste: thanks.
[16:01] <jcsackett> abentley: i can't seem to open any branchmergeproposal page on qastaging--its OOPSing on trying to open the diff. thoughts?
[16:01] <abentley> jcsackett, the librarian is FUBARed with old merge proprosals.  You could create a new one, but if you do, you'll need to manually run the scripts that update diffs.
[16:02] <abentley> jcsackett, I recommend using staging instead.
[16:02] <jcsackett> abentley: dig. thanks.
[16:02] <abentley> jcsackett, because the cron scripts are run automatically.
[16:02] <jcsackett> abentley: that makes sense.
[16:02] <jcsackett> good to know it's an issue on qastaging, not with the code.
[16:04] <flacoste> abentley: what needs to be fixed on qastaging for this to work properly?
[16:05] <abentley> flacoste, the librarian doesn't fall back to the production data correctly.
[16:05] <flacoste> abentley: do we have a RT for that?
[16:05] <flacoste> are the losa aware of this problem
[16:05] <flacoste> ?
[16:06] <abentley> flacoste, I don't know, other people discovered this problem.
[16:06] <abentley> flacoste, I just saw it discussed on IRC.
[16:07] <flacoste> abentley: do you remember who was discussing it?
[16:07] <abentley> flacoste, Sorry, no.  It was a while ago.
[16:07] <flacoste> ok, i'll investigate
[16:11] <benji> are LEPs meant to be kept up to date after they're implmented or are they simply historical?
[16:18] <flacoste> benji: historical
[16:18] <benji> cool, thanks
[17:43] <rockstar> gary_poster, ping
[17:43] <gary_poster> rockstar, pong, though I was seconds away from announcing lunchtime :-)
[17:43] <rockstar> gary_poster, just wondering where your Tarmac mp went.
[17:44] <gary_poster> rockstar: oh, thanks for following up!  I meant it to go to the lp fork, so I deleted the oe to trunk.  sorry for the noise
[17:44] <gary_poster> one
[17:44] <rockstar> gary_poster, does the bug not affect my upstream?
[17:44] <gary_poster> no rockstar
[17:45] <rockstar> gary_poster, ah, okay.  It looked like a pretty scary bug, so I was concerned.
[17:45] <gary_poster> yeah, it was interesting rockstar :-)
[17:45] <rockstar> gary_poster, thanks.  That's one less thing off my actionable list.
[17:45] <gary_poster> cool, np
[18:18] <rockstar> deryck, are you a good person to talk to about lazr-js stuff in Launchpad right now?
[18:18] <rockstar> Basically, when I take an axe to lazr-js, whose life am I making more difficult?
[18:25] <deryck> rockstar: I'm probably the best one to do that with, yes.
[18:27] <rockstar> deryck, okay.  I don't think start of it will affect you too much, as the combo loader will get pulled out first, and you don't use that anyway.
[18:27] <rockstar> deryck, but the build system will have to become part of Launchpad soon.
[18:27] <deryck> ah, ok
[18:39] <deryck> rockstar: sorry, internets are flaky in AL when it storms. ;)
[19:52] <lifeless> flacoste: what did you think of my triage mail ?
[19:53] <lifeless> flacoste: also I've forgotten the thing I was to mail you and jml about for consideration
[19:55] <flacoste> lifeless: i liked it very much! there are a few things i'd like to clarify, but overall i found it very clear
[19:55] <lifeless> awesome
[19:55] <flacoste> lifeless: i don't remember what the other email should have been
[19:55] <lifeless> what would you like to clarify ?
[19:56] <flacoste> in the triaging guidlines, you didn't specify the bucket to use
[19:56] <flacoste> i think you did that on purpose
[19:56] <flacoste> maybe not
[19:56] <lifeless> yeah, it was
[19:56] <flacoste> you only say 'in front'
[19:56] <flacoste> later than
[19:56] <flacoste> etc
[19:57] <flacoste> i understand the intent, but i think to be practical, we need to be more explicit
[19:57] <lifeless> the problem with saying 'bucket x' is that we then have a scale problem: a large number of bugs matching <that rule> will swell <that bucket> without swelling our engineering resources etc
[19:57] <flacoste> right
[19:57] <flacoste> but we only have buckets
[19:57] <flacoste> so 'in front' doesn't really mean anything
[19:58] <lifeless> I can expand on that
[19:58] <lifeless> (because it does mean something :))
[19:58] <flacoste> i know it does :-)
[19:59] <flacoste> but what it means operationally isn't clear
[19:59] <lifeless> in that document we're saying that what we want is bugs that are less important than 'the least important in the high bucket' are low
[19:59] <lifeless> and that queue jumpers only are critical
[20:01] <lifeless> flacoste: so, we could do an experiment without an explicit rule->bucket mapping for 'high', and see if its hard for folk, or if the results after a week or two are inconsistent with what you'd like to have seen
[20:01] <flacoste> so a bug escalated by a stakeholder would be marked critical?
[20:01] <lifeless> flacoste: I think so, when we accept it.
[20:01] <flacoste> ok
[20:01] <flacoste> we will need to change our DefinitionOfCritical
[20:02] <flacoste> well, rename it to DefitionOfAnIncident
[20:02] <lifeless> flacoste: I think we need to make the definitionofcritical more clearly talk about operational incidents vs code changes
[20:02] <flacoste> but i think that would be a good change
[20:02] <flacoste> agreed
[20:02] <lifeless> hah yes +1
[20:03] <lifeless> poolie and I had an interesting discussion about 'how many high bugs should we have'
[20:04] <lifeless> we expect about 1000 bugs closed a year by maintenance team work
[20:04] <lifeless> tha suggests the critical backlog (https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=timeout,oops) to be cleared in ~ 3 months
[20:05] <lifeless> and after that ~ 500 bugs in high every 6 months
[20:05] <lifeless> its possible that having 700 bugs in high (as we do) isn't a problem per se: thats a 9 month queue, yes, but in 9 months most bugs will still sort into the same bucket
[20:06] <lifeless> flacoste: what do you think?
[20:07] <flacoste> lifeless: that's my analysis also
[20:07] <flacoste> and we should have a much shorter queue in a couple of months
[20:07] <lifeless> flacoste: we'll see some movement, yes.
[20:07] <lifeless> flacoste: I'd like to try tightening up the 'front' etc stuff in that section before we try making it more fixed
[20:08] <lifeless> flacoste: because by the july epic we'll be needing to promote medium bugs to high - the goal posts should be shifting
[20:09] <lifeless> flacoste: at the very least I'd like to do a re-triage of high bugs before writing declarative rules for what should be high
[20:09] <lifeless> (so that the rules can reasonably match :))
[20:09] <flacoste> lifeless: doing it like in your proposal would remove the need for a 'escalated' tag -- which i was toying with to mark out the queue jumper in the High bucket
[20:10] <lifeless> flacoste: we may want such a tag for convenience in recall ('where are the escalated stakeholder bugs')
[20:10] <flacoste> right
[20:10] <flacoste> but we wouldn't need to hunt for it
[20:10] <lifeless> but it wouldn't be needed for 'what do I need to work on next'
[20:10] <flacoste> they would sort at the top because of their critical priority
[20:10] <lifeless> right
[20:11] <lifeless> and the initial critical bucket if we implement my proposal will be ~ 3 months deep
[20:11] <lifeless> which is good
[20:11] <lifeless> not brilliant
[20:11] <lifeless> but a good starting point to clean up from
[20:11] <flacoste> lifeless: OOPS, timeout and regression -> Critical ?
[20:11] <lifeless> + escalted
[20:11] <flacoste> + escalated
[20:11] <flacoste> works for me though
[20:12] <lifeless> https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=regression
[20:12] <lifeless> 6 bugs
[20:13] <flacoste> 172 oops
[20:13] <flacoste> and 58 timeout
[20:13] <lifeless> yeah
[20:19] <lifeless> flacoste: ok, so IIUC you're actually ok as-is now with a little tightening around the meaning of front etc - perhaps a use case.
[20:19] <lifeless> flacoste: were there other things in it that you'd like to clarify?
[20:19] <flacoste> lifeless: no, that was it, really
[20:20] <flacoste> lifeless: i found the whole rationale very clear
[20:20] <lifeless> excellent
[20:28] <henninge> jcsackett: I subscribed you to a bug on staging where our QA is failing. I am investigating.
[20:28] <henninge> s/on staging//
[20:28] <jcsackett> henninge: thanks for the heads up.
[20:47] <thumper> arse
[20:47]  * thumper wonders how to fix this
[20:48] <lifeless> flacoste: popping into the doctor with Lynne, back soon
[20:52] <flacoste> lifeless: ttyl
[20:53] <thumper> flacoste: I have an issue with recipe builds
[20:53] <flacoste> thumper: what's the issue?
[20:53] <flacoste> (/me is on a call)
[20:53] <thumper> flacoste: an early design decision was to have the recipe builds live under the recipe for the canonical url
[20:53] <thumper> however the recipe for the build is now optional
[20:53] <thumper> in order to maintain some traceability
[20:53] <flacoste> meaning that the recipe can be deleted?
[20:53] <thumper> which means we have some recipe builds without recipes
[20:54] <thumper> which are "dead"
[20:54] <flacoste> right
[20:54] <thumper> yes, the recipe can be deleted
[20:54] <thumper> but the builds live on
[20:54] <flacoste> create a graveyard parent?
[20:54] <thumper> well...
[20:54] <flacoste> in canonical_url, pseudo-code:
[20:54] <thumper> I wanted to have them hang off the ppa
[20:54] <thumper> like ppa binary builds
[20:55] <thumper> however both the binary build and the recipe build have exported themselves
[20:55] <thumper> so in order to keep the wadl stable, we can't really change them
[20:55] <flacoste> thumper: the URL isn't in the wadl
[20:55] <thumper> I'd ideally like to move both binary builds and recipe builds to live under the same URL
[20:55] <thumper> isn't it?
[20:55] <thumper> that's interesting
[20:55] <flacoste> it's not
[20:56] <thumper> ~user/+build/<buildfarmjobid>
[20:56] <flacoste> only the schema is part of the wadl
[20:56] <thumper> hmm...
[20:56] <thumper> so this may well be fine then
[20:56] <flacoste> the url is part of the documentation
[20:56] <thumper> ok
[20:56] <thumper> perhaps I may bug wgrant about this when he is up
[20:56] <thumper> just to make sure I don't fubar anything important
[20:57] <abentley> flacoste, wow, really?  We have a RESTful API that doesn't specify the URLs of anything?
[20:57] <flacoste> abentley: we don't because everything is discoverable
[20:57] <flacoste> through introspection
[20:57] <flacoste> _link
[20:58] <flacoste> you get a resource and then navigate the object graph
[20:58] <thumper> abentley: lucky us I guess :)
[20:58] <flacoste> or call methods and get back references
[20:58] <flacoste> only the service root is a well-known name
[21:00] <abentley> thumper, kinda.  I'm not sure whether our javascript would handle URL changes gracefully.
[21:00] <thumper> abentley: what do you mean?
[21:01] <abentley> thumper, it doesn't use launchpadlib, so it may have hand-crafted URLs in places.
[21:02] <thumper> I don't think we have many of those...
[21:02] <thumper> I could be wrong
[21:04] <abentley> thumper, I'm changing merge proposals so that only recently-used proposal targets are suggested.  Where should I test it?  Test the widget?  Extract a vocabulary and test that?  Test the +register view?  The current tests are pagetests.
[21:05] <thumper> I think test the widget, or test the code that the widget uses
[21:10] <flacoste> abentley: we usually don't generate url directly in the JS
[21:10] <flacoste> well we shouldn't
[21:11] <flacoste> the LP.client is the launchpadlib analog
[21:11] <flacoste> or they are generated properly server-side
[21:19] <elberry> hello, I need some help installing launchpad in a VM.
[21:20] <elberry> After getting rocketfuel-setup, and running it. I'm prompted for my launchpad username. It doesn't seem to work though. Whenever I type in my lp username and password, I continue to get the password prompt.
[21:21] <elberry> and I'm unable to get past this point as simply hitting enter after being prompted for my username results in the default username being used.
[21:21] <leonardr> flacoste: i believe we do generate lots of urls in the js, because the ajax environment doesn't support navigation the way a custom client does
[21:52] <flacoste> leonardr: right, but usually either server-side, isn't?
[21:52] <flacoste> by or by using the json dump of the context
[22:02] <gary_poster> poolie, lifeless, we'd like input from one or both of you on https://bugs.launchpad.net/launchpad/+bug/636193 .  Might be quick reply, might not.
[22:02] <_mup_> Bug #636193: feature flags need to self document <feature-flags> <lp-foundations> <Launchpad itself:Triaged by benji> < https://launchpad.net/bugs/636193 >
[22:12] <wgrant> thumper: It should be fine. Just change the PPA +build traversal to use PackageBuild instead of BinaryPackageBuild.
[22:12] <thumper> wgrant: actually we are considering /+build/<build-farm-job-id>
[22:12] <thumper> wgrant: for all build farm jobs
[22:13] <thumper> wgrant: which includes the translation jobs
[22:13] <wgrant> thumper: Translation jobs don't have an archive.
[22:13] <thumper> wgrant: so removing the inside part of binary package buids
[22:13] <thumper> wgrant: exactly
[22:13] <thumper> no archive
[22:13] <wgrant> I don't immensely like the sound of that.
[22:13] <wgrant> But perhaps.
[22:13] <thumper> wgrant: that way we have a consistent url for all build farm jobs
[22:14] <wgrant> PackageBuilds are naturally contained within an archive. It makes sense to have the traversal under an archive.
[22:15] <thumper> wgrant: the question becomes "do we want consistency for all jobs" or "do we want the containment"
[22:15] <thumper> wgrant: since translation jobs don't have archives
[22:15] <thumper> wgrant: they are not currently traversable
[22:15] <wgrant> thumper: Jobs are not primarily jobs.
[22:15] <thumper> wgrant: but we may well be interested in the state or log files
[22:15] <wgrant> Jobs exist to serve their assigned tasks.
[22:16] <wgrant> The assigned task should come first, not the jobness.
[22:17] <thumper> wgrant: you could argue that the build jobs happened on builders, so that is the natural parent
[22:17] <thumper> (I'm not saying that I am arguing that)
[22:17] <thumper> abentley brought up the argument of "why treat translations differently?"
[22:19] <wgrant> thumper: Jobs don't have builders to start with, so that can't work.
[22:19] <wgrant> And I think translations jobs probably belong under a branch.
[22:19] <thumper> good point
[22:22] <thumper> wgrant: do all binarypackagebuilds now have a buildfarmjob id ?
[22:22] <thumper> wgrant: through the packagebuild table?
[22:23] <wgrant> thumper: Yes.
[22:23] <thumper> wgrant: we could have uniqueness through either the package build id, or the build farm job id
[22:23] <thumper> wgrant: since there is already a buildfarmjobset that gets jobs through the id, and the specific job method
[22:23] <thumper> wgrant: I'd be inclined to use that
[22:24] <wgrant> Probably.
[22:57] <gary_poster> hey poolie.  We wanted your and/or lifeless' input on https://bugs.launchpad.net/launchpad/+bug/636193
[22:57] <_mup_> Bug #636193: feature flags need to self document <feature-flags> <lp-foundations> <Launchpad itself:Triaged by benji> < https://launchpad.net/bugs/636193 >
[22:58] <gary_poster> For one, benji took that.  If you really want it, just let us know. :-)
[22:58] <poolie> yay benji!
[22:58] <gary_poster> lol :-)
[22:58] <gary_poster> For another, we have some implementation questions.  benji put them on the bug, so you can see what the story is there
[22:58] <poolie> i'm going to the rally tomorrow so i'm not likely to work on it fro the next few weeks
[22:58] <poolie> i see
[22:59] <poolie> but perhaps benji and i can pair at the thunderdome? that could be fun
[22:59] <gary_poster> that could be fun, though we've been asked to bring these tasks to completion so feature flags can be declared "done"
[23:00] <gary_poster> thunderdome isn't too far away though :-)
[23:00] <gary_poster> if you can give us some quick direction, please do; otherwise, you can make that request/suggestion :-)
[23:00] <poolie> i will do that on the bug
[23:00] <gary_poster> many thanks
[23:00] <poolie> right now
[23:00] <gary_poster> even better ;-)
[23:01] <poolie> he (or you) are welcome to give me a call any reasonable time to talk about things if you want to
[23:01] <poolie> even if i'm not answering irc
[23:01] <poolie> between say 08:00 and 19:00 utc+11
[23:01] <poolie> (not next week of course)
[23:01] <gary_poster> awesome, thank you
[23:01] <gary_poster> right :-)
[23:02] <lifeless> gary_poster: I've commented on the bug FWIW
[23:02] <gary_poster> oh, lifeless, thanks!  sorry, I didn't see.  I still need to set up my mail rules in some new clever way :-/
[23:02] <lifeless> gary_poster: oh, I just did now when yo umentioned it
[23:03] <gary_poster> lol, oh ok, cool
[23:03] <lifeless> I has a -big- mail backlog
[23:03] <gary_poster> ;-) gotcha
[23:03] <lifeless> 10K messages over my holiday
[23:03] <lifeless> down to 9K as of this morning
[23:03] <gary_poster> heh, congrats
[23:04] <gary_poster> need to run.  night all
[23:39] <bryceh> When I run launchpad via 'make run', and then browse around, each page takes several minutes to load.  In the make run output I see it printing a huge number of apache log messages about transferring language files
[23:39] <bryceh> e.g. GET /+icing/rev9918/yui/datatype/lang/datatype_zh-Hans.js
[23:39] <lifeless> tip should be better
[23:39] <lifeless> be sure to do make jsbuild
[23:39] <bryceh> lifeless, well I can't get tip because rocketfuel-get fails
[23:39] <bryceh> on mailman
[23:40] <lifeless> bryceh: yeah, I linked the bug to you in this channel
[23:41] <bryceh> lifeless, no, I looked at that bug but is seems to not be relevant.  The files they say are missing, are present, and the versions/names of packages it said to load are already present on the system.
[23:42] <lifeless> ok
[23:42] <lifeless> not sure then
[23:48] <bac> StevenK, thumper, mwhudson, wgrant, lifeless: you all around for a reviewers meeting?
[23:48] <thumper> I'm around
[23:48] <bac> top o' the hour?
[23:48] <thumper> aye