maxb | Urgh | 00:21 |
---|---|---|
maxb | bzr-tarmacland breaks 'bzr selftest' | 00:21 |
poolie | maxb, as in, it has failing tests, or it breaks it entirely? | 00:30 |
lifeless | popping into supermarket back in a bit | 00:30 |
maxb | as in, it has code in its tests that failed to import, so the entire execution dies | 00:52 |
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:29 | |
thumper | gah, my landing failed due to the non [testfix] nature | 01:39 |
* thumper leaves the devel fix to wgrant | 01:39 | |
thumper | wgrant: is it obvious? | 01:40 |
wgrant | thumper: Yes. | 01:42 |
wgrant | thumper: Just running the Bugs tests now. | 01:42 |
wgrant | (the test suite was clearly not run over the problematic branch :/) | 01:43 |
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:05 |
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:06 |
lifeless | interesting | 02:08 |
lifeless | hmm, possibly we've broken mailman on lucid by fixing for natty>< | 02:08 |
lifeless | sinzui: ^ | 02:08 |
StevenK | So we're aiming for Lucid, Maverick and Natty? | 02:09 |
lifeless | we deploy on lucid. | 02:10 |
lifeless | its mandatory until a new LTS is ready | 02:11 |
lifeless | everything else I don't particularly care about :) | 02:11 |
=== Ursinha-afk is now known as Ursinha | ||
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:31 | |
thumper | spm: not me | 02:32 |
wgrant | spm: Wha? LP doesn't have passwords. | 02:33 |
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:34 |
spm | click the 'change' button and get a "No! Password not set! bad Losa!" error message. | 02:35 |
lifeless | file a bug | 02:36 |
spm | nearly completed. I was ranting here so the bug won't be quite so vitrolic. | 02:37 |
spm | :-) | 02:37 |
lifeless | === Top 10 Time Out Counts by Page ID === | 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:37 |
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:38 |
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:44 |
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:45 | |
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:49 |
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:50 |
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:51 |
lifeless | thumper: what would that leave behind? why isn't it just s/message/comment/ (and thus not very interesting) | 02:52 |
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:53 |
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:54 |
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. | 02:57 | |
thumper | wgrant: if it is a testfix, rs=me | 03:02 |
wgrant | thumper: https://code.launchpad.net/~wgrant/launchpad/makeBug-testfix/+merge/45200 | 03:03 |
thumper | wgrant: done | 03:05 |
wgrant | thumper: Thanks. | 03:06 |
lifeless | poolie: around? | 03:55 |
poolie | lifeless, hi | 04:04 |
lifeless | poolie: call ? | 04:04 |
poolie | lifeless, hi, now? | 04:16 |
lifeless | https://dev.launchpad.net/BugTriage | 04:19 |
lifeless | https://bugs.launchpad.net/launchpad-project/+bugs | 04:23 |
lifeless | wgrant: hey | 06:03 |
lifeless | stub: hi | 06:03 |
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:04 |
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:05 |
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:07 |
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:08 |
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:09 |
stub | I can try to reproduce slow queries using random ids in the IN clause, but genuine data will work better. | 06:10 |
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:11 |
lifeless | ok, I need to run for a while to organise dinner | 06:12 |
stub | wgrant: I can run a query on production to generate the list of ids if that helps | 06:15 |
wgrant | stub: Thanks. I'll work one out soonish. | 06:16 |
=== almaisan-away is now known as al-maisan | ||
al-maisan | Good morning ! | 06:31 |
wgrant | Morning al-maisan. | 06:32 |
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 > | 06:55 |
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:24 |
wgrant | stub: We should have them. But that should be fairly cheap regardless, right? | 07:26 |
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:27 |
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:33 |
stub | lifeless: http://paste.ubuntu.com/550516/ with random ids and buildfarmjob.status IN (1,2) (both statuses are fairly large categories) | 07:38 |
lifeless | so its having to generate temp datasets | 07:41 |
lifeless | both of which are being built and sorted rather than delivered from indices | 07:42 |
lifeless | it also looks to be highly correlated | 07:44 |
lifeless | stub: are both halves of the union equally expensive? | 07:45 |
stub | lifeless: roughly | 07:48 |
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:50 |
stub | Where do you see that? I see 1067 and 908 | 07:53 |
stub | Oh... actual time. I'm using estimated time. Actual time will be affected because rows will already be in RAM | 07:54 |
lifeless | welll. run it twice ;) | 07:55 |
lifeless | we've seen mismatches between estimate and actual that matter before, haven't we? | 07:56 |
stub | Interesting Gnome lockup... | 08:05 |
stub | Anyway... | 08:05 |
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:06 |
adeuring | good morning | 08:35 |
mrevell | Morning | 08:58 |
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:04 |
wgrant | mpt: https://pastebin.canonical.com/41512/, but it's a couple of months out of date. | 11:14 |
mpt | wgrant, brilliant, thanks. | 11:14 |
=== Ursinha-afk is now known as Ursinha | ||
=== matsubara-afk is now known as matsubara | ||
deryck | Morning, all. | 12:02 |
wgrant | mpt: Are we? | 12:32 |
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:33 |
wgrant | Excellent, excellent news. | 12:34 |
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:40 |
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:41 |
leonardr | thanks, i'm guessing that was the problem | 12:45 |
leonardr | trying again now | 12:45 |
leonardr | "using machine image version 504" | 12:46 |
wgrant | Looks good. | 12:46 |
=== leonardr is now known as leonardr-afk | ||
=== mrevell is now known as mrevell-lunch | ||
=== yofel_ is now known as yofel | ||
=== matsubara is now known as matsubara-lunch | ||
=== mrevell-lunch is now known as mrevell | ||
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! | 14:59 |
gmb | Ta | 15:00 |
jcsackett | henninge: ping. | 15:20 |
henninge | Hi jcsackett! | 15:20 |
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:21 |
henninge | jcsackett: I plan to finish tomorrow around this time. I don't expect any problems atm. | 15:22 |
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:23 |
=== matsubara-lunch is now known as matsubara | ||
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:52 |
EdwinGrubbs | flacoste: it's done, I just marked it now. | 15:53 |
flacoste | thanks EdwinGrubbs! | 15:53 |
jcsackett | flacoste: qaing it now. | 15:53 |
=== deryck is now known as deryck[lunch] | ||
=== salgado is now known as salgado-lunch | ||
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. | 15:58 |
flacoste | jcsackett: you might ask abentley for help with that problem | 16:00 |
jcsackett | flacoste: thanks. | 16:00 |
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:01 |
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:02 |
flacoste | abentley: what needs to be fixed on qastaging for this to work properly? | 16:04 |
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:05 |
abentley | flacoste, I don't know, other people discovered this problem. | 16:06 |
abentley | flacoste, I just saw it discussed on IRC. | 16:06 |
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:07 |
=== leonardr-afk is now known as leonardr | ||
benji | are LEPs meant to be kept up to date after they're implmented or are they simply historical? | 16:11 |
flacoste | benji: historical | 16:18 |
benji | cool, thanks | 16:18 |
=== beuno is now known as beuno-lunch | ||
=== Ursinha is now known as Ursinha-lunch | ||
=== salgado-lunch is now known as salgado | ||
=== deryck[lunch] is now known as deryck | ||
=== al-maisan is now known as almaisan-away | ||
=== benji is now known as benji-lunch | ||
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:43 |
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:44 |
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 | 17:45 |
=== gary_poster is now known as gary-lunch | ||
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:18 |
=== Ursinha-lunch is now known as Ursinha | ||
deryck | rockstar: I'm probably the best one to do that with, yes. | 18:25 |
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:27 |
=== benji-lunch is now known as benji | ||
deryck | rockstar: sorry, internets are flaky in AL when it storms. ;) | 18:39 |
=== beuno-lunch is now known as beuno | ||
=== gary-lunch is now known as gary_poster | ||
lifeless | flacoste: what did you think of my triage mail ? | 19:52 |
lifeless | flacoste: also I've forgotten the thing I was to mail you and jml about for consideration | 19:53 |
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:55 |
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:56 |
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:57 |
lifeless | I can expand on that | 19:58 |
lifeless | (because it does mean something :)) | 19:58 |
flacoste | i know it does :-) | 19:58 |
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 | 19:59 |
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:01 |
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:02 |
lifeless | poolie and I had an interesting discussion about 'how many high bugs should we have' | 20:03 |
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:04 |
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:05 |
lifeless | flacoste: what do you think? | 20:06 |
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:07 |
lifeless | flacoste: because by the july epic we'll be needing to promote medium bugs to high - the goal posts should be shifting | 20:08 |
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:09 |
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:10 |
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:11 |
lifeless | https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=regression | 20:12 |
lifeless | 6 bugs | 20:12 |
flacoste | 172 oops | 20:13 |
flacoste | and 58 timeout | 20:13 |
lifeless | yeah | 20:13 |
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:19 |
flacoste | lifeless: i found the whole rationale very clear | 20:20 |
lifeless | excellent | 20:20 |
=== almaisan-away is now known as al-maisan | ||
=== henninge_ is now known as henninge | ||
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:28 |
=== salgado is now known as salgado-afk | ||
thumper | arse | 20:47 |
* thumper wonders how to fix this | 20:47 | |
lifeless | flacoste: popping into the doctor with Lynne, back soon | 20:48 |
flacoste | lifeless: ttyl | 20:52 |
=== matsubara is now known as matsubara-afk | ||
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:53 |
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:54 |
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:55 |
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:56 |
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:57 |
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 | 20:58 |
=== al-maisan is now known as almaisan-away | ||
abentley | thumper, kinda. I'm not sure whether our javascript would handle URL changes gracefully. | 21:00 |
thumper | abentley: what do you mean? | 21:00 |
abentley | thumper, it doesn't use launchpadlib, so it may have hand-crafted URLs in places. | 21:01 |
thumper | I don't think we have many of those... | 21:02 |
thumper | I could be wrong | 21:02 |
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:04 |
thumper | I think test the widget, or test the code that the widget uses | 21:05 |
flacoste | abentley: we usually don't generate url directly in the JS | 21:10 |
flacoste | well we shouldn't | 21:10 |
flacoste | the LP.client is the launchpadlib analog | 21:11 |
flacoste | or they are generated properly server-side | 21:11 |
elberry | hello, I need some help installing launchpad in a VM. | 21:19 |
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:20 |
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:21 |
flacoste | leonardr: right, but usually either server-side, isn't? | 21:52 |
flacoste | by or by using the json dump of the context | 21:52 |
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:02 |
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:12 |
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:13 |
wgrant | PackageBuilds are naturally contained within an archive. It makes sense to have the traversal under an archive. | 22:14 |
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:15 |
wgrant | The assigned task should come first, not the jobness. | 22:16 |
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:17 |
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:19 |
thumper | wgrant: do all binarypackagebuilds now have a buildfarmjob id ? | 22:22 |
thumper | wgrant: through the packagebuild table? | 22:22 |
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:23 |
wgrant | Probably. | 22:24 |
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:57 |
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:58 |
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" | 22:59 |
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:00 |
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:01 |
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:02 |
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:03 |
gary_poster | need to run. night all | 23:04 |
=== gary_poster is now known as gary-afk | ||
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:39 |
lifeless | bryceh: yeah, I linked the bug to you in this channel | 23:40 |
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:41 |
lifeless | ok | 23:42 |
lifeless | not sure then | 23:42 |
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 | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!