LPCIBot | Project db-devel build #764: STILL FAILING in 6 hr 2 min: https://lpci.wedontsleep.org/job/db-devel/764/ | 00:00 |
---|---|---|
wallyworld | jtv: you back on board yet? | 00:17 |
poolie | wallyworld: hello, can you review https://code.launchpad.net/~xaav/loggerhead/export-tarball/+merge/66408 | 00:56 |
poolie | and merge it if appropriate | 00:57 |
wallyworld | poolie: sure | 00:58 |
wallyworld | that one was marked as needing info for a while i think | 00:58 |
poolie | it stalled for a bit | 00:59 |
poolie | if people push and don't ask for more review it's easy for things to get stuck | 01:00 |
poolie | which is https://bugs.launchpad.net/launchpad/+bug/745469 i guess | 01:12 |
_mup_ | Bug #745469: please send notifications when merge page has been updated with new revisions <code-review> <Launchpad itself:Triaged> < https://launchpad.net/bugs/745469 > | 01:12 |
wallyworld | poolie: in the above case, i normally add a comment to the mp explaining what i did and why and how it relates to any previous request for change | 01:23 |
wallyworld | this causes an email to be sent | 01:23 |
poolie | yup | 01:23 |
poolie | it's not obvious that you ought to do this though | 01:23 |
poolie | ought/need | 01:23 |
wallyworld | too true | 01:23 |
lifeless | fixing up aaron's incremental diff thing will address that - and get sensible incremental diffs with merges from trunk (which the loggerhead based diff thing does not do) | 01:39 |
LPCIBot | Project devel build #928: STILL FAILING in 5 hr 37 min: https://lpci.wedontsleep.org/job/devel/928/ | 01:49 |
wallyworld | lifeless: can you +1 this? i'm not 100% familar with loggerhead etc but it seems reasonable and has had a lot of input already.... https://code.launchpad.net/~xaav/loggerhead/export-tarball/+merge/66408 | 02:28 |
poolie | thanks wallyworld | 02:32 |
poolie | to merge it, when you're ready, you should be able to just merge into lp:loggerhead | 02:33 |
poolie | and i guess it would be good to deploy that to lp too | 02:33 |
wallyworld | poolie: np. i'll clean up the lint first | 02:33 |
wallyworld | poolie: i may need to ask for help deploying - i've had nothing to do with loggerhead so far :-) | 02:34 |
poolie | np | 02:46 |
poolie | i'm getting "lib/canonical/launchpad/icing/yui/yui/yui.js" in my lp checkout | 02:46 |
poolie | oh, a broken symlink or something, isn't it | 02:47 |
wallyworld | poolie: likely. a make clean will fix it | 02:50 |
wallyworld | will || should | 02:50 |
lifeless | are there any tests of the personmerge view other than the doctest ? | 05:06 |
LPCIBot | Project db-devel build #765: STILL FAILING in 5 hr 40 min: https://lpci.wedontsleep.org/job/db-devel/765/ | 05:41 |
lifeless | hahaha | 05:49 |
wgrant | ? | 05:50 |
lifeless | -> ops | 05:50 |
lifeless | wgrant: are there unit tests for person.merge() ? | 06:15 |
wgrant | I doubt it. But let's see.. | 06:17 |
lifeless | I can't see any in test_person | 06:17 |
wgrant | There is a _do_merge in test_person. | 06:18 |
wgrant | Is that not relevant? | 06:18 |
wgrant | I haven't actually seen anything beyond its existence. | 06:18 |
lifeless | nothing in there looking for notifications that I can see | 06:18 |
lifeless | which is what I'm touching | 06:18 |
wgrant | :/ | 06:18 |
lifeless | and \o/ | 06:29 |
lifeless | can has review ? | 06:33 |
lifeless | https://code.launchpad.net/~lifeless/launchpad/bug-761874/+merge/69748 | 06:33 |
lifeless | wgrant: ^ or wallyworld ^ | 06:44 |
lifeless | wallyworld: I will look at the loggerhead thing monday; it requires some pagination | 06:44 |
wallyworld | lifeless: ok, thanks. will look at your mp | 06:44 |
lifeless | wallyworld: deployment is the usual thing - update the version we use, and qa that once that commit hits qa-staging | 06:44 |
wallyworld | ok | 06:44 |
=== jtv-afk is now known as jtv | ||
=== wallyworld changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 240 - 0:[#######=]:256 | ||
poolie | cheerio wallyworld | 07:21 |
poolie | what's the idiomatic way to html-escape things in lp python code? | 07:21 |
wgrant | Don't do it. | 07:22 |
wallyworld | poolie: i'll do that mp on monday when it gets +1ed | 07:22 |
wgrant | poolie: What are you trying to do? | 07:22 |
wgrant | Escaping is usually the wrong thing. | 07:22 |
wallyworld | wgrant: you want to mentor: ://code.launchpad.net/~lifeless/launchpad/bug-761874/+merge/69748 ? | 07:22 |
poolie | wgrant: test_scope_documentation_displayed is checking that the feature scopes are in the browser.contents | 07:23 |
poolie | it's failing to find them, i think because the new one i've added contains angle brackets | 07:23 |
wgrant | Ah, so this is in a test? | 07:23 |
wgrant | Just use cgi.escape. | 07:23 |
poolie | heh :) ok | 07:23 |
LPCIBot | Project devel build #929: STILL FAILING in 5 hr 34 min: https://lpci.wedontsleep.org/job/devel/929/ | 07:24 |
poolie | i agree with not having random escaping and unescaping in production code | 07:24 |
adeuring | good morning | 07:35 |
poolie | hi abel | 07:42 |
poolie | could someone do a review for me, on https://code.launchpad.net/~mbp/launchpad/mail-scope/+merge/60281 | 07:42 |
adeuring | poolie: I'll look | 07:52 |
poolie | thanks | 07:53 |
lifeless | wallyworld: still here ? | 07:55 |
lifeless | wallyworld: you asked for create to mention delete, but I do that in my patch already. | 07:55 |
lifeless | wallyworld: do you mean you want the interface to talk about implementation ? | 07:55 |
* lifeless loads the question | 07:55 | |
=== adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring | Critical bugs: 240 - 0:[#######=]:256 | ||
adeuring | lifeless: could you have a look at this mp: https://code.launchpad.net/~adeuring/launchpad/bug-739052/+merge/69625 | 07:57 |
lifeless | adeuring: hahha, on friday night no less. | 08:01 |
lifeless | adeuring: great stuff | 08:01 |
adeuring | lifeless: thanks! | 08:01 |
bigjools | morning | 08:12 |
poolie | o/ | 08:14 |
=== almaisan-away is now known as al-maisan | ||
mrevell | hallo there bigjools | 08:15 |
poolie | ok, good night | 08:26 |
lifeless | adeuring: reviewed | 08:41 |
adeuring | lifeless: thanks! | 08:42 |
lifeless | adeuring: no probs | 08:52 |
bigjools | wgrant: need a chat with you | 08:53 |
bigjools | adeuring: morning! I have a lovely branch for you if you can take it please? | 09:05 |
adeuring | bigjools: sure | 09:05 |
bigjools | adeuring: https://code.launchpad.net/~julian-edwards/launchpad/utf-codes-in-emails-bug-817106/+merge/69758 | 09:06 |
wgrant | bigjools: Not entirely here, but what's up? | 09:06 |
bigjools | wgrant: I wanted to talk about the no-builds-in-progress check in the IDSJ, and whether/how we should fix the packagecopier | 09:07 |
bigjools | I am very concerned | 09:07 |
wgrant | Your concern is well-placed. | 09:08 |
bigjools | wgrant: so I'd rather mumble/skype. If now is bad, next week is ok. | 09:09 |
wgrant | bigjools: Next week is probably best, sorry. | 09:09 |
bigjools | not a problem | 09:09 |
bigjools | thanks | 09:09 |
adeuring | bigjools: the diff on the MP page shows a minor merge conflict | 09:10 |
bigjools | adeuring: ah I'll fix that, thanks | 09:12 |
bigjools | adeuring: conflict fixed, just waiting for the branch scanner | 09:22 |
adeuring | bigjools: thanks | 09:22 |
adeuring | bigjools: r=me | 09:38 |
bigjools | adeuring: thank you sir. Did the unicode stuff look ok? I figured you'd have more experience of that than me :) | 09:38 |
adeuring | bigjools: as I wrote in the MP, we used something like u'Lo\u2345c' and avoided the "coding: utf-8" line at the top | 09:39 |
bigjools | ah ok | 09:39 |
adeuring | bigjools: but | 09:39 |
adeuring | I thin k we can really switch to the way you did it | 09:39 |
bigjools | I took inspiration from a different python file in our tree | 09:40 |
adeuring | bigjools: even better then :) | 09:40 |
bigjools | Loïc looks better than Lo\u2345c huh? :) | 09:40 |
adeuring | there is a small risk that somebody uses an editor which does not understnd utf-8 | 09:40 |
adeuring | but I am not aware of any such editors... | 09:40 |
bigjools | yeah - I had issues with Vim but then it seems all ok with it today :/ | 09:41 |
adeuring | bigjools: and yeah, this '\u3456' looks really ugly and is sometimes hard to understand | 09:41 |
bigjools | indeed | 09:42 |
jml | lifeless: can you please merge: lp:~jml/python-fixtures/misc-fixes | 09:42 |
adeuring | I think Python supports also something like "LATIN_CAPITAL_A_WITHDIERESIS" with some escape mechanism but that's not much better than \u1234 | 09:43 |
bigjools | heh | 09:44 |
bigjools | it is a total minefield | 09:44 |
adeuring | bigjools: not such a big pitfall as some Qt unicode -> string conversion method (can't remember which one exactly) It gave you ISO8859-1 strings by default. Was quite annoying for any language spoken that did not originate in western europe | 09:47 |
bigjools | adeuring: nice. | 09:48 |
cjwatson | https://dev.launchpad.net/LaunchpadPpa says "The current development series [...] (currently: natty)" and "The current release [...] (currently: maverick)" | 10:14 |
cjwatson | should that be changed to oneiric and natty respectively now? | 10:15 |
wgrant | Indeed. It does work on oneiric. | 10:15 |
cjwatson | launchpad-dependencies has versions 0.95~oneiric1, 0.95~natty1, 0.95~lucid1. lp:meta-lp-deps only has 0.95. Is that done by hand? How do you deal with different versions of dependencies in different releases? | 10:17 |
bigjools | jtv: the expander sections on the queue syncs look nicer now | 10:17 |
cjwatson | oh, hm, https://code.launchpad.net/~launchpad/+recipe/meta-lp-deps-on-demand | 10:17 |
jtv | bigjools: Thanks. Actually expanding does look more appropriate on an expander, does it not? | 10:17 |
bigjools | jtv: generally :) | 10:18 |
jtv | BTW it looks like the other expanders don't get the colspan quite right. | 10:18 |
jtv | My eye keeps expecting a link where the archive name is. Is there anything to link to? | 10:19 |
wgrant | cjwatson: Right, that recipe is used. The deps are identical between series these days, though, so the series-specific sources are unnecessary. | 10:19 |
cjwatson | I guess I can use substvars to force the right versions of apt/python-apt | 10:19 |
cjwatson | cleaner than series-specific sources | 10:20 |
wgrant | Slightly. | 10:20 |
wgrant | maverick doesn't have a sufficient version? | 10:20 |
cjwatson | no | 10:20 |
wgrant | That is inconvenient. | 10:21 |
cjwatson | bigjools has copied stuff into the PPA now (including maverick), but I assume that that won't necessarily get upgraded without forcing versions in lp-deps | 10:21 |
wgrant | Sometimes we force it, sometimes we don't... | 10:21 |
cjwatson | Should I just not bother? | 10:22 |
wgrant | Probably not. Only the two buildbots + cocoplum really need it. | 10:23 |
wgrant | And we can ensure that those are correct easily. | 10:23 |
wgrant | And it avoids the substvar mess. | 10:23 |
cjwatson | it's mildly inconvenient that cocoplum doesn't seem to have the Launchpad PPA in sources.list | 10:24 |
wgrant | Right, the DC machines use CAT. | 10:24 |
wgrant | We generally import stuff from the PPA into CAT. | 10:24 |
cjwatson | so I should RT that? it's just for apt/lucid | 10:24 |
wgrant | Not sure. LOSAs ^^? | 10:24 |
* mthaddon catches up | 10:25 | |
mthaddon | yeah, an RT asking for it to be uploaded to the -cat repos and installed would be good | 10:26 |
cjwatson | OK | 10:26 |
mthaddon | cjwatson: unf we can't install directly from PPAs on servers in the DC as that would basically mean a compromise of LP would root all DC servers | 10:26 |
mthaddon | s/would/could/ | 10:26 |
wgrant | Erm... | 10:26 |
wgrant | You know what controls the Ubuntu archive, yeah? :) | 10:26 |
mthaddon | well, that's true, but it's a slightly different case | 10:27 |
wgrant | The security of the primary archive is less tested, yes. | 10:27 |
cjwatson | I'd normally use the ubuntu-platform@ RT address, but I assume I should use the launchpad@ address in this case ... | 10:29 |
=== jtv is now known as jtv-eat | ||
cjwatson | wgrant: assuming that the buildbots are up to date or will update, then https://code.launchpad.net/~cjwatson/launchpad/dpkg-xz-support-619152 could be landed now, I believe | 10:31 |
wgrant | cjwatson: Has it been through ec2 lately? | 10:32 |
cjwatson | No | 10:33 |
bigjools | wgrant: can you help the dude in #launchpad? | 10:34 |
cjwatson | mthaddon: done, RT#47110 | 10:45 |
_mup_ | Bug #47110: [UNMETDEPS] php4-yaz links against old libmysqlclient <php4-yaz (Ubuntu):Fix Released> < https://launchpad.net/bugs/47110 > | 10:45 |
mthaddon | thx | 10:45 |
mthaddon | cjwatson: do you know if this has been tested on staging/dogfood? | 10:47 |
allenap | adeuring: Would you be able to review a mostly JavaScript branch for me? https://code.launchpad.net/~allenap/launchpad/localpackagediffs-filter-by-person-or-team-bug-798873-ui/+merge/69766 | 11:05 |
adeuring | allenap: sure | 11:05 |
allenap | Thanks :) | 11:06 |
allenap | adeuring: I am going to get some lunch now but I'll try to watch for pings. Is that okay? If not, leave it for later when I'm back. | 11:06 |
adeuring | allenap: then let me ytart my lunch break too before I start to look at the mp :) | 11:07 |
allenap | adeuring: Cool :) | 11:07 |
LPCIBot | Project db-devel build #766: STILL FAILING in 5 hr 43 min: https://lpci.wedontsleep.org/job/db-devel/766/ | 11:24 |
bigjools | """Gina's changelog parser and muncher for great justice""" | 11:29 |
jml | am thinking of doing work to address / mitigate https://bugs.launchpad.net/launchpad/+bug/814725 | 11:53 |
_mup_ | Bug #814725: No feedback between upload & acceptance/rejection <Launchpad itself:Triaged> < https://launchpad.net/bugs/814725 > | 11:53 |
jml | james_w suggested adding an API method for upload | 11:53 |
jml | any thoughts from folk here? bigjools? wgrant? StevenK? | 11:54 |
bigjools | jml: it's not a trivial problem | 11:54 |
wgrant | Until we have a message queue. | 11:55 |
bigjools | an API for upload is not going to work, it'll time out | 11:55 |
wgrant | Until then, best not to think about it :) | 11:55 |
bigjools | we need to decide what feedback people would be happy with | 11:56 |
jml | bigjools: so the timeout starts from 'request received'? | 11:56 |
jml | or rather, request started | 11:56 |
jml | rather than, say, request finished | 11:56 |
wgrant | jml: The processing itself can easily take many seconds. | 11:57 |
bigjools | jml: to make sure we're talking about the same thing, is that a webservice API? | 11:57 |
bigjools | s/seconds/minutes/ | 11:57 |
jml | bigjools: yes. | 11:57 |
jml | why minutes? | 11:57 |
bigjools | jml: ok, that will never work. we need a different transport | 11:57 |
bigjools | jml: the upload processor has to unpack the package | 11:58 |
bigjools | that can take a loooong time | 11:58 |
jml | why does it need to do that? | 11:58 |
bigjools | to verify its contents | 11:58 |
wgrant | It should never take minutes, but it can have to un-xz and un-bz2 a few hundred megabytes :/ | 11:58 |
bigjools | "should" :) | 11:58 |
bigjools | jml: at a stretch we could make poppy poke something into the database to say "pending uploads +=1" and then make the upload processor decrement that. Then the UI can show something. | 11:59 |
bigjools | not sure of the ramifications of that though | 12:00 |
jml | bigjools: well, there are other checks that are fast to do that the user would be well served to be told about sooner | 12:00 |
jml | e.g. permission checks | 12:00 |
bigjools | jml: yes, they are all done first | 12:00 |
wgrant | I have considered deferring the extraction to a job. | 12:01 |
jml | bigjools: yeah, but currently asynchronously | 12:01 |
wgrant | We could possibly get away with removing a couple of the pedantic checks on the extracted package. | 12:01 |
bigjools | jml: I think it doesn't try to unpack unless all the other stuff passes | 12:01 |
jml | I can't see any mention of tarfile in archiveuploader | 12:01 |
wgrant | And then do the file retrieval async. | 12:01 |
wgrant | jml: Hahah | 12:01 |
wgrant | dpkg-source | 12:01 |
bigjools | anyway - there's a load of bugs which means it'll just OOPS | 12:01 |
wgrant | Not that easy :) | 12:01 |
jml | wgrant: ah, ok. got it. | 12:01 |
* bigjools has deja vu | 12:02 | |
wgrant | archiveuploader is a bit special. | 12:02 |
wgrant | Not gina-special. | 12:02 |
wgrant | But still fairly special. | 12:02 |
* bigjools found a horrible bug in gina | 12:02 | |
bigjools | it doesn't help when the doctest that checks for output format doesn't have a -NORMALIZE_WHITESPACE :/ | 12:02 |
jml | afaict, the verification here is just for 'single directory', 'changelog' and 'copyright' | 12:03 |
jml | I guess dpkg-source might do verification that the code implicitly relies on. | 12:03 |
wgrant | bigjools: While you're there, want to fix archiveuploader's changelog_entry generation? | 12:04 |
bigjools | what aspect? | 12:04 |
wgrant | jml: Right. dpkg-source does a lot of checks. | 12:04 |
jml | why not check the first by listing the tarball contents, and get the other two by just extracting those files? | 12:04 |
wgrant | jml: But if we accept an invalid package, it will just fail to build, so it's not that bad. | 12:05 |
wgrant | Extracting those files how? | 12:05 |
wgrant | We'd have to be able to unpack all the source formats. | 12:05 |
wgrant | Untar + diff | 12:05 |
wgrant | Or untar + untar | 12:05 |
wgrant | Or whatever they come up with next. | 12:05 |
bigjools | accepting invalid packages to the build farm is nuts, don't do that | 12:05 |
wgrant | bigjools: They are rare and will just end up FAILEDTOBUILD. It's not *that* bad. | 12:06 |
bigjools | it's build time wasted | 12:06 |
jml | wgrant: hmm. I see. I guess you'd have to patch upstream to provide the feature. | 12:06 |
bigjools | disk space wasted | 12:06 |
bigjools | and crufty | 12:06 |
jml | bigjools: every successful check is wasted CPU too | 12:06 |
bigjools | reject early, reject often | 12:07 |
bigjools | jml: no, it's just getting deferred | 12:07 |
bigjools | the later you reject in a pipeline that has a lot of steps, the harder it is to produce a decent error message | 12:10 |
jml | Certainly failing early is good. | 12:11 |
jml | But if you are doing an expensive check early that is also implicitly done in later steps, you are penalizing successful cases to help the bad ones. | 12:11 |
bigjools | in this case I disagree; you're just pushing the penalty to later on | 12:12 |
wgrant | Perhaps we should get some data. | 12:14 |
jml | but it's actually making it take longer, isn't it? Or is the output of dpkg-source in the upload check saved so that the build farm doesn't need to run it? | 12:14 |
wgrant | I suspect it's very rare that dpkg-source fails. | 12:15 |
jml | wgrant: yeah, that'd be interesting to see. | 12:15 |
jml | funnel graphs | 12:15 |
wgrant | No, all the buildds have to rerun it. | 12:15 |
bigjools | so assuming most uploads are actually OK, then you're right. But yeah we need data on that. | 12:15 |
bigjools | I still think we need to check this stuff :) | 12:16 |
wgrant | I'm also not quite sure on how a webservice API would work here. | 12:17 |
bigjools | it wouldn't | 12:17 |
wgrant | I guess you'd upload files to the librarian and then fire off an MQ-based job. | 12:17 |
wgrant | It's doable, and should be done eventually :) | 12:17 |
bigjools | please not the librarian | 12:18 |
wgrant | They would have a <24h expiry. | 12:18 |
=== bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring, bac | Critical bugs: 240 - 0:[#######=]:256 | ||
bac | hola abel | 12:19 |
jml | still probably need a MQ though. | 12:19 |
bigjools | the way we do it is fine. We can make poppy send a message to something to kick off processing | 12:19 |
bigjools | I'd like to parallelise per archive (up to a max thread count) | 12:19 |
wgrant | Indeed. | 12:20 |
wgrant | It would be nice if Python did threads :/ | 12:20 |
bigjools | heh | 12:20 |
wgrant | Maybe by the time we have a MQ-based jobrunner we will have moved to PyPy. | 12:21 |
* bigjools can't believe this changelog parsing bug has been in Gina so long | 12:21 | |
jml | well | 12:21 |
bigjools | wgrant: haha | 12:21 |
jml | we'll see what I actually need to get my thing done. | 12:22 |
bigjools | jml: in lieu of a message, another solution would be to have some sort of pending upload indicator in IArchive which poppy increments and the upload processor decremements | 12:23 |
wgrant | jml: Recipes! | 12:23 |
jml | wgrant: I asked for in-page updates for async jobs for every feature LP did since January 2010. Including recipes. | 12:23 |
bigjools | jml: when we finish DDs, we'll be finishing *that* :) | 12:23 |
jml | bigjools: looking forward to it. | 12:24 |
bigjools | hellyes | 12:24 |
wgrant | Bug #628738 | 12:24 |
_mup_ | Bug #628738: SourcePackageRelease.changelog_entry now incorrectly generated <lp-soyuz> <soyuz-upload> <Launchpad itself:Triaged> < https://launchpad.net/bugs/628738 > | 12:24 |
wgrant | bigjools: That's the bug. | 12:24 |
wgrant | (also not caught because of NORMALIZE_WHITESPACE, IIRC) | 12:25 |
bigjools | yay | 12:25 |
bigjools | different problem to the one I am fixing though | 12:25 |
wgrant | doctests, yay | 12:25 |
wgrant | Yeah. | 12:25 |
bigjools | there's nothing like testable documentation | 12:25 |
bigjools | and our doctests are nothing like testable documentation | 12:26 |
jml | except maybe burgers with turds in them. | 12:26 |
* bigjools blinks | 12:26 | |
adeuring | allenap: r=me | 12:28 |
allenap | Thanks adeuring :) | 12:28 |
bigjools | wgrant: do you know if iron is in NDT? | 12:32 |
wgrant | bigjools: It is. | 12:32 |
wgrant | mcmurdo too. | 12:32 |
bigjools | good | 12:32 |
bigjools | I love the way that someone thought that list.append(string) included a newline | 12:33 |
wgrant | ftpmaster, ppa, librarian, librarian2, mailman, codehosting are not in nodowntime. | 12:33 |
wgrant | Everything else is. | 12:33 |
wgrant | mailman might be as of 12 hours ago. I forget. | 12:33 |
wgrant | And codehosting will be on monday. | 12:34 |
wgrant | Shall be good. | 12:34 |
bigjools | woo | 12:34 |
=== jtv-eat is now known as jtv | ||
cjwatson | mthaddon: TTBOMK it has not | 12:46 |
mthaddon | cjohnston: ok, I've added a note to the ticket that we should do that first, so we'll make it so | 12:46 |
cjwatson | great, thanks | 12:46 |
jml | cjwatson: that's a new acronym for me. | 12:47 |
jml | excellent. no more learning required from me for the rest of the day. | 12:47 |
* cjwatson prescribes jml alcohol | 12:53 | |
cjwatson | mthaddon: do I need to take that backlogged message seriously, or is it automatic irrelevancy? | 12:53 |
mthaddon | cjwatson: it basically just means it hasn't been directly assigned to someone yet, but I've given in a priority, and if that needs bumping up it can be done at any time | 12:54 |
mthaddon | s/given in/given it/ | 12:54 |
jml | cjwatson: with prescriptions like that, perhaps there's more to be said for private medical practitioners than I had previously thought! | 12:54 |
cjwatson | mthaddon: ok, cool | 12:54 |
deryck | Morning, all. | 13:08 |
jtv | Hi bac! Free for a review? I've got this: https://code.launchpad.net/~jtv/launchpad/bug-818032/+merge/69791 | 13:42 |
bac | jtv: sure | 13:43 |
jtv | Thanks. | 13:43 |
bac | jtv: did you have any pre-implementation discussions about this bug and branch? | 13:45 |
jtv | bac: yes, hence the "pre-implementation notes" :) | 13:45 |
jtv | With Julian, to be precise. | 13:45 |
bac | jtv: ok. since you didn't list any one in that section i wanted to find out. | 14:01 |
jtv | bac: in retrospect I see I wasn't very helpful in that section, sorry. | 14:04 |
bac | jtv: looks good. thanks! | 14:04 |
jtv | thank you. | 14:04 |
=== stub1 is now known as stub | ||
abentley | adeuring or bac: could you please review https://code.launchpad.net/~abentley/launchpad/fix-lpviews/+merge/69800 ? | 14:27 |
bac | abentley: i will | 14:27 |
adeuring | bac: you bebat me :) | 14:27 |
abentley | bac: I have fixed the lint. | 14:27 |
bac | i did bebat you! | 14:27 |
bac | abentley: done. good catch. | 14:39 |
abentley | bac: thanks. | 14:40 |
bac | i didn't realize we had pages using the zope default | 14:40 |
jcsackett | sinzui: i see that you are working on 800361. i just unassigned myself from that in lp; shall i assign you? | 15:04 |
sinzui | jcsackett, I suppose | 15:06 |
jcsackett | sinzui: is there a reason i shouldn't? i only unassigned myself b/c i'm not currently working further on it after UI tests and thought someone else might have the time to do it. which seemed to be you. | 15:07 |
sinzui | jcsackett, I have been very distracted the last two days and have made no progress. If I am distracted today, I will give up the work to wallyworld. This is critical path work and I not certain I should ever be on the critical path | 15:08 |
jcsackett | sinzui: ok. leave it till monday and decide then? | 15:08 |
sinzui | jcsackett, I have been working to unblock others. I am participating in the product strategist interviews | 15:09 |
jcsackett | sinzui: aaah. | 15:09 |
sinzui | jcsackett, do you have time to mumble? | 15:09 |
jcsackett | sinzui: sure. | 15:09 |
gary_poster | bigjools, is there anyone with a somewhat overlapping timezone to mine whom I can bother about a relatively simple soyuz question (https://answers.launchpad.net/launchpad/+question/166346 fwiw)? I'm sorry I've been bothering you a lot lately. | 15:22 |
bigjools | gary_poster: that doesn't look like a soyuz question | 15:23 |
gary_poster | oh | 15:23 |
bigjools | project release stuff isn;t it? | 15:23 |
* gary_poster feels dumber... | 15:23 | |
gary_poster | ok | 15:24 |
gary_poster | bac...do you have any idea about https://answers.launchpad.net/launchpad/+question/166346 ? | 15:24 |
bigjools | gary_poster: oh and I think the answer is "no" anyway :( You've got 2 Aussies, and me. | 15:24 |
gary_poster | bigjools, heh, ok, thanks | 15:25 |
=== al-maisan is now known as almaisan-away | ||
bac | sorry, gary your message didn't get highlighted. maybe my client doesn't like "bac..." | 15:47 |
bac | gary_poster: i can't answer that question off the top of my head. i'm not familiar with how that pattern is used. i can look into it, though. | 15:50 |
gary_poster | thanks bac. maybe on your CHR rotation. I'm not pursuing it | 16:14 |
=== beuno is now known as beuno-lunch | ||
=== adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: bac | Critical bugs: 240 - 0:[#######=]:256 | ||
jml | mrevell: did you just put Welsh on the Launchpad blog? | 16:28 |
=== deryck is now known as deryck[lunch] | ||
dobey | hey guys | 16:50 |
dobey | i got OOPS-2036MPJ10 from lp trying to generate a diff for my branch | 16:51 |
dobey | i think it might be a bug in bzr or something | 16:51 |
jelmer | hi dobey | 16:56 |
jelmer | hmm, that OOPS hasn't synced yet | 16:57 |
dobey | ok | 17:01 |
dobey | jelmer: it probably says something akin to this, anyway: http://pastebin.ubuntu.com/654553/ | 17:01 |
LPCIBot | Project db-devel build #767: STILL FAILING in 5 hr 38 min: https://lpci.wedontsleep.org/job/db-devel/767/ | 17:03 |
=== beuno-lunch is now known as beuno | ||
jelmer | dobey: that's a known bug | 17:17 |
jelmer | a 5 digit bug even | 17:17 |
jelmer | bug 82555 | 17:17 |
_mup_ | Bug #82555: Merging to an empty branch doesn't work <merge> <Bazaar:Confirmed> < https://launchpad.net/bugs/82555 > | 17:17 |
dobey | wow | 17:20 |
jelmer | dobey: while you're here... :) | 17:22 |
jelmer | dobey: did you see my mps against lptools? | 17:22 |
dobey | yeah, but i haven't had time to look at them. i guess poolie hasn't either | 17:23 |
jelmer | there's no hurry | 17:24 |
dobey | that bug is interestingly odd | 17:29 |
dobey | since it is possible to merge to an empty branch, but weird things can happen | 17:29 |
dobey | if i just merge to the empty branch and commit straight away, it sort of 'rights' itself | 17:30 |
dobey | so, this is interesting... | 17:33 |
dobey | jelmer: http://pastebin.ubuntu.com/654630/ <- notice the revnos that are listed as negative :) | 17:34 |
dobey | and log -n0 shows them as 1..5 | 17:35 |
jelmer | dobey: yeah, there seem to be multiple issues here | 17:37 |
jelmer | dobey: this sort of thing is tricky because of the way we do revno assignment, as you can see :) | 17:37 |
dobey | sure | 17:38 |
gmb | bac: I have a branch that needs reviewing, if you've got time: https://code.launchpad.net/~gmb/launchpad/remove-unused-potmsgsets/+merge/69841 | 17:42 |
bac | gmb: i do have time. | 17:43 |
gmb | Thanks | 17:43 |
gmb | Woah. | 17:43 |
gmb | bac: Hang on. Bad diff. | 17:43 |
gmb | bac: Should have submitted against db-devel. https://code.launchpad.net/~gmb/launchpad/remove-unused-potmsgsets/+merge/69842 | 17:44 |
=== Ursinha is now known as Ursinha-lunch | ||
=== deryck[lunch] is now known as deryck | ||
bac | gmb: review done with a couple of suggestions | 18:07 |
gmb | bac: Thanks | 18:08 |
=== Ursinha-lunch is now known as Ursinh | ||
=== Ursinh is now known as Ursinha | ||
deryck | abentley: I'll be ready for our call in about 3 minutes. Meet you in mumble then? | 19:00 |
abentley | deryck: sounds good. | 19:00 |
LPCIBot | Project devel build #930: STILL FAILING in 6 hr 1 min: https://lpci.wedontsleep.org/job/devel/930/ | 19:13 |
=== almaisan-away is now known as al-maisan | ||
abentley | gary_poster: ping | 20:07 |
gary_poster | abentley, hi | 20:08 |
abentley | gary_poster: I'd like to talk about the jsoncache. Do you have a couple of minutes? | 20:08 |
gary_poster | abentley, sure, in 5 ok? | 20:09 |
abentley | gary_poster: sure. | 20:09 |
gary_poster | cool, abentley, I'll ping | 20:09 |
gary_poster | abentey, thanks, ready | 20:17 |
gary_poster | I'd prefer skype | 20:17 |
=== al-maisan is now known as almaisan-away | ||
gary_poster | abentley ping :-) | 20:24 |
* gary_poster has EoD in 5 | 20:24 | |
abentley | gary_poster: So that the Thunderdome, you expressed concern about the idea of reloading the whole JSONRequestCache as a means of updating pages. | 20:24 |
gary_poster | yeah | 20:25 |
gary_poster | at least as one to be applied as a blanket approach | 20:25 |
abentley | gary_poster: Was the concern about the size of the download or the expense of calculating it server-side? | 20:25 |
gary_poster | probably fine in some cases | 20:25 |
gary_poster | abentley, expense | 20:25 |
abentley | gary_poster: I think you suggested using ETAGs as a remedy to avoid retrieving already-known data? But wouldn't that still be expensive server-side? | 20:26 |
gary_poster | abentley, I don't remember suggesting ETAGs for this problem, but who knows. :-) My preferred solutions might be long poll pushes, and/or MVC in client-side code (which in isolation would only address part of the "curentness" problem, but would be better than what we have). | 20:29 |
abentley | gary_poster: I don't understand how MVC would address it. The +sharing-details page wants to use it, and IS MVC. | 20:32 |
abentley | gary_poster: Anyhow, I guess we can pick this up next week. | 20:34 |
gary_poster | abentley, ack. I'm glad that we have the mechanism, and my concerns/thoughts maybe can go under the category of "future work". | 20:36 |
lifeless | gmb: still her e? | 20:37 |
abentley | gary_poster: Anything I come up with will be opt-in, at least initially. But If there opportunities to support other use cases better, I don't want to miss them. | 20:37 |
gary_poster | abentley, ack. You might want to talk to wgrant; he has some thoughts about the long poll that might be nicely integrated in the future | 20:38 |
abentley | gary_poster: Yes, we've chatted about that. He was my roommate at the Thunderdome. | 20:38 |
gary_poster | abentley, heh, ok | 20:39 |
gary_poster | cool | 20:39 |
* gary_poster needs to run | 20:39 | |
gary_poster | have a good weekend abentley, all | 20:39 |
abentley | gary_poster: you too. | 20:39 |
abentley | lifeless: IIRC, we have a mechanism for a web client to control what page a form submission redirects us to. Do you know what it is? | 20:42 |
lifeless | I'm not aware of that except in the special case of the login / logout handshakes | 20:43 |
abentley | lifeless: cool, thanks. | 20:43 |
lifeless | I believe those cases are special-cased by the page being submitted to | 20:44 |
abentley | lifeless: XHR automatically follows redirects, so submitting a form via AJAX redirects to a useless page, which is a pointless roundtrip. I'd like to either avoid the redirect or redirect to a useful page. | 20:48 |
lifeless | abentley: is this the new ++ thing, or existing form submissions ? | 20:50 |
abentley | lifeless: existing form submissions, but the "useful page" would be the ++model++. | 20:51 |
lifeless | can you tell that its an ajax xhr request on the server? | 20:51 |
lifeless | abentley: also, if you're tuning this, wouldn't it be better not to redirect at all ? | 20:52 |
lifeless | the redirect exists for web clients to end up with nice urls is all. | 20:52 |
lifeless | (ah, as you say above 'avoid the redirect') +1 | 20:52 |
abentley | lifeless: Yes, it would be better to not redirect at all, but that would have to be decided server-side. | 20:52 |
abentley | lifeless: Even better would be to return the data we actually want. | 20:53 |
abentley | lifeless: I don't know whether there's a generic way to detect an XHR client, but I'm sure we could set a header or something. | 20:54 |
lifeless | I think having a 'this is xhr' flag and then calculating and returning -only- the needed data would be ideal. | 20:59 |
lifeless | it would avoid the redirect, and avoid the concerns around ++model++ doing too much work on big pages (e.g. BugTask:+index w/bug 1) | 21:00 |
_mup_ | Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Confirmed for compscibuntu-bugs> <dylan.NET.Reflection:Invalid> <dylan.NET:Invalid> <EasyPeasy Overview:Invalid by ramvi> <elementary OS:In Progress by elementaryproject> <GenOS:In Progress by gen-os> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <LibreOffice:In Progress by bjoern-michaelsen> <Th | 21:00 |
=== bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 240 - 0:[#######=]:256 | ||
lifeless | http://activitystrea.ms/ | 21:02 |
abentley | lifeless: "returning -only- the needed data", where that's a subset of the ++model++ would be quite a trick. | 21:04 |
lifeless | abentley: are we blocked on deploys until we fix all these views ? | 21:05 |
abentley | lifeless: The only known-broken view is fixed in r13560. | 21:07 |
lifeless | abentley: I'm a little worried that there are others we don't know about, and we'll find out the hard way. | 21:08 |
lifeless | abentley: is it possible to make the code gracefully handle the absence of the method (and perhaps log / write a soft oops) when that happens ? | 21:08 |
abentley | lifeless: In the words of Robert Collins, "Untested code is broken code". | 21:08 |
abentley | lifeless: Writing a soft oops would be fine with me. | 21:09 |
lifeless | I agree that untested code is broken code. We know now that we have (at least) one untested view. | 21:10 |
lifeless | If we deploy as-is and find more untested views exist, we'll have to halt all deployments, rollback the deploy - moderately expensive shenanigans | 21:11 |
abentley | lifeless: That's not the only way to handle a regression. You can also just fix it. | 21:12 |
abentley | lifeless: these fixes are trivial, e.g. a line of zcml or adding a parent class. | 21:13 |
abentley | lifeless: this morning I searched the oopses for any more affected views and didn't find any. I can search again. | 21:14 |
lifeless | reverting the deployment takes minutes; the fixing pipeline takes (minimal) 6 hours | 21:15 |
lifeless | doing a cowboy on the spot requires an incidentreport and analysis - its something we want to avoid as much as possible (perhaps too much, but thats a separate discussion) | 21:16 |
lifeless | Lynne and I are popping out, so I have to go | 21:17 |
lifeless | sorry | 21:17 |
abentley | lifeless: I just re-synced qastaging oopses and didn't find any more broken views. | 21:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!