[00:22] cprov: Is it considered a bug that the component listed for a build sometimes lies? [00:22] It can change after the build completes, if the package is promoted/demoted. [00:23] That can be a bit confusing, as the only way to work out where it really built is checking the override-sources-list line in the build log. === Ursinha-nom is now known as Ursinha [00:47] *** FYI. restarting codehosting for a Cherry Pick *** === thumper is now known as thumper-afk [02:19] * wgrant beats the AJAX milestone picker with a how-did-you-get-around-the-security-policy bat. [02:21] wgrant: sort of, it changes according to subsequent overrides. [02:21] cprov: Right. [02:22] wgrant: ideally we would store the component at the time the source was dispatched, on Build table [02:23] cprov: That's what I thought. But I guess it's rare enough that it's not worth it. [02:23] wgrant: I suspect it would be useful for spotting component mismatching. [02:23] But it might be a bit stranger when package sets come into it. [02:24] wgrant: yeah, good point ... we need to study some real use-cases. [03:04] Where would I add a test for c.l.w.tales.ObjectFormatterAPI.api_url? c.l.w.tests.test_tales doesn't seem right. [03:22] wgrant, ping [03:31] deryck: Hi. [03:32] wgrant, hi. So I see you're working on bug 415166. Thanks! [03:32] Bug #415166: Launchpad says I don't exist when I subscribe to a bug [03:32] wgrant, did you talk over your proposed fix with anyone? [03:33] deryck: No, but it is less trivial than I thought, so I will. [03:34] wgrant, yeah, I thought it there might be more than that at first appears. [03:34] wgrant, what were you thinking? [03:34] deryck: the obvious thing to do was pass rootsite='api' in ObjectFormatterAPI.api_url. [03:34] But that gives the API site, not the API bit of the main site. [03:35] wgrant, right. You get an https://api.launchpad.net... absolute URL, right? [03:35] deryck: Right. [03:36] I'm currently poking around to work out how to get an https://launchpad.net/api/beta/... [03:36] wgrant, but all the JS code assumes "me" is a relative URL, right? i.e. "/~me" [03:36] That seems like it will be very difficult, though... [03:36] deryck: Hmmmm. I suppose so. [03:38] wgrant, there are a lot of places in the js that make that assumption. That LP.client.links['me'] is a relative URL, that the links in HTML scraped by JS are relative, etc. [03:38] wgrant, so I don't think there's a single spot to fix this and have it work. [03:39] deryck: But ObjectFormatterAPI.api_url did work before. It just got broken by the canonical_url default chnage. === Ursinha is now known as Ursinha-nom [03:40] Actually, that change should have been on edge before yesterday. So maybe it isn't that. [03:41] wgrant, right. Let me say it another way. You can fix "me" to be right and I suspect subscribing may still be broken in other ways. The current bug is a symptom, not the problem. [03:41] wgrant, I got to give it to you, we open up Launchpad, and you've started fixing bugs [03:42] beuno: You didn't think I would? [03:42] * deryck is quite happy wgrant is fixing bugs! [03:42] Although I filed a lot this morning, too :( [03:42] good bug reports are never a problem, no matter the number. [03:43] deryck: Assuming that api_url gets fixed, subscribing should work. What is broken about it, besides being fragile? [03:43] wg most people don't ;) [03:43] wgrant, (tab fail) [03:43] beuno: True. [03:43] I imagine that will change over time. [03:45] wgrant, first, if "me" isn't relative the Subscriber js object won't initialize correctly, and second, unsubscribing won't work because the links in HTML won't be relative either. [03:46] wgrant, allow the second point may just be DOM update fail. the unsubscribe API call may not depend on the HTML href. Can't recall right now. [03:46] * deryck is up late [03:47] deryck: You are probably right. This is indeed looking more difficult. [03:47] I forgot about team unsubscription. [03:48] it's a tangled web. inline subscribing is actually very complex. [03:49] wgrant, I'm not trying to discourage you though. Please keep at it! :) [03:49] Should I leave it to you, then? [03:49] OK. [03:49] wgrant, just didn't want you to be disappointed if you fixed "me" and the rest was still borked. [03:49] Ah. [03:50] wgrant, deryck: wouldn't fixing fmt:api_url to always return a relative url fix the problem? [03:50] wgrant, and naturally if you work out any of the rest, or see hints of whats going on in light of what you know now, you'll be better able to file bugs on the rest. :) [03:51] BjornT: I think so. [03:51] BjornT: I'm testing team unsubscription now. [03:51] BjornT, I'm not sure. [03:52] BjornT, I thought we relied on user links in the DOM being relative, and so the API call may succeed, but if fmt:link was used, and it isn't relative, it may look like a fail in the UI. [03:53] deryck: Team unsubscription doesn't use the fmt:link URLs. [03:53] I'm not sure how it gets the other ones, though... [03:54] wgrant, what do you mean by "other ones"? [03:54] deryck: I can see it making webservice requests with a person of https://bugs.launchpad.dev/~team [03:55] deryck: But fmt:link should now give https://launchpad.dev/~team [03:56] wgrant, I think everything other than "me" is inferred from DOM. or the subscriber_ids object. [03:57] wgrant, BjornT -- ok, so maybe I've just added confusion. sorry. :) And now I must sleep if I'm to be worth anything the coming morning. :) [03:57] * wgrant digs into the JS. [03:57] Night deryck. [03:57] Fixing the me-link was as easy as I initially suspected after all. [03:57] good deal then [03:57] (just needed rootsite=None, not rootsite='api') [03:57] ok, night [03:59] wgrant: can i see the patch? i think there might be another solution [04:00] BjornT: bzr diff is being a little slow, but I just replaced c.l.w.tales.ObjectFormatterAPI.api_url's self.url() call with self.url(rootsite=None) [04:01] As various subclassess now specify rootsite='mainsite' as the default. [04:01] This reverts to the previous behaviour. [04:02] wgrant: ok, that's a sane solutoin. but i have a question for you. why not change api_url() to always return a relative path? [04:03] BjornT: That's what it does. [04:03] Although maybe that's just by accident -- I haven't dug all the way down the call stack. [04:04] wgrant: not really. canonical_url() can't always return a relative url. note the parameter name: 'path_only_if_possible' [04:05] wgrant: note that i don't know the answer to this question, and i don't expect you to either :) but it's worth thinking about. [04:06] wgrant: in short, i think your patch is good, since it reverts to the old behaviour. i would go with your patch, and raise the issue i mentioned on the list. [04:08] wgrant: btw, did you manage to write a test for this? [04:10] BjornT: Sorry, the switch got angry and decided my packets were unworthy of retransmission... [04:10] I haven't written a test, no. === thumper-afk is now known as thumper [04:11] I'm about to find the best place to put it. [04:11] Is there some repository of class-specific TALES tests somewhere? [04:12] Ahh. [04:12] c/l/doc/tales.txt [04:12] I didn't expect there to be anything there, as the others are in c/l/w/tests/test_tales.py [04:14] wgrant: unfortunetaly, i think that tales.txt is the right place for now. it seems like api_url() is untested :( [04:14] BjornT: It is. [04:14] Not for much longer, hopefully. [04:16] BjornT: Should I just add api_url tests for the three problematic classes, next to the tests that show fmt:link always goes to the mainsite? [04:16] Or should I add a new section? [04:19] wgrant: i think there should at least be a section for fmt:api_url [04:24] wgrant: do you know how to go about making the test fail without your fix? [04:25] BjornT: Um, what? You mean running the test? [04:27] wgrant: nope. i meant writing the test, so that the pre-conditions are the same as in the bug report [04:28] BjornT: what time is it for you right now? [04:28] Oh, right. [04:28] thumper: I was wondering that... [04:29] Isn't it like 06:30 over there? [04:29] thumper: 6.30 am. woke up a bit earlier than usual today [04:30] BjornT: I think I can fairly safely just check that api_url returns something relative, although I suppose that isn't testing exactly what we want. [04:30] wgrant: what you probably want to test is that the fmt:api_url always returns api.launchpad.net as the base [04:31] thumper: No, that's exactly what we don't want. [04:31] so perhaps something like: [04:31] no? [04:31] what is the problem then? [04:31] wgrant: i think such a check is ok. i do suspect that you need to do some setup to make api_url return a relative url [04:31] I must have misunderstood [04:31] thumper: api_url is actually a path-only absolute URL. [04:31] thumper: Nothing to do with the API, except that it's used by some flaky JS. [04:31] wgrant: and what is it doing right now? [04:32] thumper: Returning an absolute URL to the main site, since fmt:url for person/team/pillar was changed to do that by default. [04:32] wgrant: why would it be wrong to check that the urls are always api.launchpad.net? [04:33] thumper: Because they should never have a domain, and api.launchpad.net is particularly we don't want -- api.launchpad.net isn't usable from the webapp. [04:33] wgrant, thumper: to be more exact, it's returning the url to the mainsite, unless calling it from the mainsite [04:34] BjornT: Indeed. [04:34] BjornT: ok [04:34] wgrant: I'd make sure then that you test with the main pillars [04:35] wgrant: created by the factory, and test the explicit url with test_tales [04:35] wgrant: person, product, project, distribution [04:36] thumper: Thanks. [04:36] But first... lunch. [05:17] Some of these factory tests don't seem to be much better than the sample data ones. [05:17] I'd even say they're worse. [05:17] Some depend on the order in which objects were created. [05:17] So I throw in an innocent makeProduct and makePerson, and some of the subsequent tests start complaining that the numbers in the names are different. [05:19] wgrant: haha [05:19] wgrant: and here comes the magic of the factory [05:19] wgrant: factory.makePerson(name="eric") [05:20] wgrant: always provide what you want to test to the factory [05:20] thumper: Right. But I'm going to have to fix other bits of the test. [05:20] So it's a bug that the other tests test the name, but don't provide it? [05:20] wgrant: so if you are checking the url, make sure you don't have unspecified parts [05:20] wgrant: yes, that is very wrong [05:21] But now I have to come up with more names ;'( [05:21] wgrant: ask and I will provide [05:21] wgrant: foo, bar, baz, fubar, widget, frobrisher [05:21] those are what I use [05:21] except for the last one [05:21] I just made that up [05:21] Haha. [05:22] I use eric a lot for my random person [05:22] because there is no eric in the sample data, and I like Eric the Viking [05:22] I've seen a few of him. [05:22] probably me [05:22] eric, john, graham, michael, terry [05:22] I'm sure you could think of a few more [05:22] wgrant: for multiple people, I also use abe, bob, charles, dave [05:22] xray, yankee, zulu for teams [05:40] thumper: not "Eric the 'alf a Viking"? [05:40] spm: :) [05:43] I use random naming schemes, depending on what's on my mind at the time. [05:49] rockstar: there is a 3.0 branch for some code-import pages if you are up for it [05:51] thumper, I'll look at it in the morning. Trying not to break my stride right now. [05:52] Also, my media server's PSU just died, so I don't even get music anymore... :/ [06:08] How does the JS build system work? [06:08] what do you mean? [06:09] Do I make changes in lib/canonical/launchpad/javascript, and 'make run' will propogate those changes to lib/canonical/launchpad/icing/build? [06:11] Oh. [06:11] They're symlinks. [06:11] That's easy, then. [06:13] wgrant: I am tired but it think the answer to your question is that we have a script in utilities that scans the template we list the scripts in. The utility builds he compressed js. [06:13] sinzui: But that's not relevant for development purposes? [06:14] No, but it is relevant to YUI.Test. I recall have to run make build a few times. [06:14] Ah. [06:14] Thanks. [06:16] I think the issues related to the html page that acts as a harness. It wants the built libs plus the lib under test. [06:18] sinzui: hi, got a minute [06:18] for a question? [06:18] sinzui: what's the status of the new breadcrumbs? [06:18] sinzui: I sent out an email earlier [06:19] I may not have a comprehensible answer [06:19] To fix unsubscribing of teams, LP.client.normalize_uri needs to be convinced to prepend the root when operating on an absolute URL, which it currently explicitly doesn't do. Does anybody know why, before I go hunting? [06:20] thumper salgado proposed a generic mechanism that will DTR thing on most cases to flacoate. I believe there are exceptions and there will be a way to change the bread crumb [06:20] sinzui: yeah, I figured we'd need to annotate the breadcrumbs for branches [06:21] sinzui: which was the main point of my email, "what do we show" [06:21] sinzui: here's another idea [06:21] thumper I wont know more until salgado wakes and I attain some form of caffeine induces consciousness. [06:21] sinzui: rename code -> branches for the "tab", and add a "code" tab for projects that goes to loggerhead [06:21] +1 [06:21] I'll copy that into an email for beuno [06:22] I recall beuno_ wanted to do that, I wonder if that was shelved to 4.0 as being too invasive for 8 weeks of development [06:24] sinzui: lets see [06:40] BjornT: Is it a sufficiently civilised time to request a review from you? [06:41] I figure I'll get this fairly clean branch out of the way, rather than landing one polluted with JS changes as well. === thumper is now known as thumper-afk [06:44] Ugh. Why do we even have a test like notfound-traversals ? [06:44] rockstar: I deleted a few today [06:44] sinzui, it just fails with something that looks entirely unrelated. [06:45] It's impossible to debug, it's a dumping ground for tests. [06:45] rockstar: why do we test nofound + do pagetest 404 + view check_permissions? I think some drugs were involved [06:46] * sinzui only writes view check_permissions tests and deletes all others. [06:46] If drugs are a requirement, I suggest that they be administered as part of rf-setup. [06:46] rockstar: I think notfound was originally for URL that we wanted to retire. It is now an opportunity to not write a good test [06:47] sinzui, yes, I would agree. I'm willing to bet most of the code stuff in notfound-traversals is tested elsewhere in a better manner. [06:51] notfound-traversals was a reaction to poor test coverage. A quick way to ensure the pages at least rendered, at a minimum. [06:52] (or generated the correct error code in the first round, hence the name) [06:52] I agree it should wither and die [06:55] It'll probably shave eleventy billion minutes off the total time to run the test suite as well. [06:59] Dangit. Looks like I got a little overzealous while deleting templates. One test failure left though. === lionel_ is now known as lionel [08:26] good morning [08:26] hi adeuring :) [08:27] hi noodles775! === danilo-afk is now known as danilos [08:44] danilos: Do you think it's time to make a merge proposal for https://code.edge.launchpad.net/~lantash/launchpad/bug-392154 ? I guess I'm supposed to write a merge proposal as suggested at https://dev.launchpad.net/DetailedCoverLetterTemplate and send a contributor agreement to you or kiko. What about running the whole test suite? [08:45] lantash: hi, let me take a glance at it [08:46] lantash: about the full test suite, it's generally preferred to do it ('make check'), but if it's problematic for you, running "bin/test -vvt lp.translations" (takes <15 minutes on my machine) should be enough [08:47] danilos: Thanks. I'll do that. Don't hesitate to tell me if you dislike anything about the newly introduced code or if there's anything missing. [08:47] lantash: looking at the revision log, I'd say you are mostly ready to submit it for review [08:48] lantash: don't worry, I am not shy about it, though it's very much appreciated you spent your time to help us improve Launchpad :) [08:55] wgrant: Hi. Anybody looking at your MP already? [08:56] henninge: No. I discussed the patch with BjornT and deryck earlier, but if it seems sane to you then go ahead. [08:56] henninge: i'm looking at it now [08:57] Thanks BjornT. [08:57] BjornT: I already have, was about to review [08:57] BjornT: so you can save your time if you want ... ;-) [08:57] henninge: were you about to start reviewing, or write up the review? [08:57] the latter [08:58] BjornT: ^ [08:58] henninge: ok, go ahead then [09:00] danilos: For some reason, my bin/ directory is gone. Looks like "make clean" removed it, which seems to have been invoked by "make check" (which failed by the way: "Error: Couldn't find a distribution for 'zc.buildout==1.4.0dev-gary-r102684'."). Can you tell me how to regenerate it? [09:00] lantash: once you merged with trunk, some dependencies (listed in versions.cfg) have changed; it should be enough for you to cd into download-cache and do a 'bzr up' there [09:00] And then 'make' again. [09:01] lantash: and do 'make' again, as wgrant said (if it's not clear he was continuing on what I said :) [09:04] danilos,wgrant: It works fine now. Thanks! I'd run "make lint" too, but unfortunately, it fails on my 9.04 machine: "pkg_resources.DistributionNotFound: pylint==0.18.0" [09:04] lantash: Odd. download-cache is up to date? [09:05] And the branch is up to date with devel? [09:07] wgrant: If you mean running "bzr up" in download-cache and "bzr merge lp:launchpad/devel", then yes. I ran both commands just seconds ago. Just FYI, this isn't a new issue, I've never been able to successfully run "make lint" since I branched lp. [09:08] lantash: Odd. It has always worked fine for me on Jaunty and Karmic. [09:08] lantash: Do you have the pylint package installed? [09:09] wgrant, lantash: I don't see pylint in versions.cfg, so I'd expect that you'd need to install it yourself [09:09] wgrant: yeah, I'll check there's a version I installed by hand that conflicts with the one in the repositories. [09:09] of course, launchpad-developer-dependencies should do it for you, but there might be a bug [09:09] maxb: Do you want to find a sponsor to get the necessary stuff from ~maxb/launchpad into ~launchpad/ppa to get things working on Karmic, or shall I? [09:13] Hello my friends :) [09:14] hi mrevell [09:14] hey there hijacker_ :) [09:14] * mrevell cuts down on the smilies [09:15] wgrant: did some investigation. ;-) [09:15] pylint 0.18 (which is required by lp) is in /usr/lib/python.2.6/dist-packages [09:15] pylint 0.15.2 can be found in /usr/lib/python.2.[45]/site-packages as well as pyshared (0.15.2 is in the Jaunty repos). [09:17] I am trying to submit a remote branch (wgrant's) to ec2test and pqm but ec2test complains like this: [09:17] To send email, a remotely accessible smtp_server (and smtp_username and smtp_password, if necessary) must be configured in bzr. See the SMTP server information here: https://wiki.canonical.com/EmailSetup . [09:17] I know I have done this before so I wonder if something changed about this. [09:18] for the record: yes, the smtp server is configured ... [09:19] henninge: Other people have repushed it, I think. [09:20] But I'm no expert on sponsoring... [09:22] henninge: smtp server is probably configured for your LP repo, and not for remote others' repos; you can try moving smtp settings to your global bzr config [09:22] Ok, now it is working. I moved the smtp configuration from location.conf to bazaar.conf [09:22] henninge: that's it :) [09:22] danilos: ;-) [09:23] wgrant: ok, branch is in ec2test and will find it's way into the tree. Thanks again. [09:23] henninge: Thanks! [09:24] lantash: note that LP uses python 2.4, so it'll probably try to use pylint 0.15.2, and that should be fine; it's probably 0.18 installation that causing the problems [09:33] wgrant: Hi, I was just thinking about that. The proper way would be to cherrypick my changes into individual small branches and submit those one by one, right? [09:34] Or, is submitting a branch with a one-line change considered a bit of a waste of time, and should I try to batch unrelated small changes? [09:34] maxb: I mean the PPA packages. [09:34] Oh, right [09:34] Just for 2.4 now. [09:34] Since that works, and is better than nothing. [09:34] Well, works for you :-) [09:34] Well, yes. Rather odd. [09:35] I guess I should try to talk to flacoste about that, based on the authorship of most of the packages in ~launchpad/ppa [09:36] Probably. [09:37] danilos: Removing /usr/local/pylint as well as the 0.18 installation solved the problem. Thanks! Fortunately, the changed files are lint clean. [09:38] lantash: cool, let me know once MP (merge proposal) is up, so we can move to #launchpad-reviews to discuss it :) [09:39] I'm really annoyed with myself, I carefully started using launchpad~maxb in .deb versions in my ppa with the intent that launchpad versions would be higher when official. But then I did some uploads whilst too sleepy, and made some of them maxb~launchpad instead [09:42] bigjools: is this something you can help maxb with? ^ [09:42] not much I can do about that [09:43] No, the version numbering is entirely my screwup [09:43] you could start a new PPA === thumper-afk is now known as thumper [09:43] thumper! working late? [09:43] bigjools: hey [09:43] bigjools: yeah, just a bit [09:44] Well, yeah, but the numbers are in the wild now, the PPA's advertised on dev.lp.net and I know people are using it [09:44] Anyway [09:44] I would like to help populate the ~launchpad ppa for karmic. What is the preferred form for submitted packages for sponsored upload / copy into there? [09:44] good question [09:45] check with flacoste when he's around later, but if necesarry we can add you as a named uploader [09:45] ok, if I don't catch flacoste later today, I'll ask launchpad-dev@ [09:47] Separate topic - I'd like to start submitting code changes to support python2.5 - I thought I'd start small, with this one: http://bazaar.launchpad.net/~maxb/launchpad/python2.5/revision/8974 [09:47] if I have a security wrapped product [09:47] and adapt it to something else [09:47] Are branches with a one-line change wanted, or is it better to try to collect a few one-liners into a single branch? [09:47] does the something else get security wrapped? [09:47] * thumper thinks not [09:48] maxb: one liners are fine [09:48] maxb: several one liners together are fine [09:48] maxb: several 50 line fixes should be broken up [09:48] maxb: keep changes easily reviewable [09:48] maxb: that's your axiom [10:04] thumper: I think it does [10:04] once wrapped, always wrapped [10:04] bigjools: adaptation doesn't go through a secured utility [10:04] have you tried it? [10:04] by accident once [10:04] bigjools: but I have a test I'm writing [10:05] I remember seeing some code somewhere that used an adapter so that we got proxied objects [10:06] bigjools: I'll let you know :) [10:06] thumper: I'll honestly be very surprised if an adapter turns a proxied object into a non-proxied one [10:07] bigjools: well, the adapter is a class that takes the wrapped object as a parameter [10:07] Don't trusted adapters get proxied (but get unproxied access to the wrapped object)? [10:07] bigjools: so it won't wrap the new object [10:07] But IIRC non-trusted adapters don't get proxied, but rely on the proxy around the wrapped object. [10:07] wgrant: where are the docs about trusted adapters? [10:07] uhoh, ajax bug subscribe broken on edge for everyone or just me? [10:08] maxb: yep, broken [10:08] maxb: I have a branch landing for that ATM. [10:08] thumper: No idea. I just remember this from when I played with some Zope 3 code a couple of years back. [10:08] * wgrant Googles. [10:09] thumper: http://docs.zope.org/zope3/ZCML/http_co__sl__sl_namespaces.zope.org_sl_zope/adapter/index.html, the trusted attribute seems relevant. [10:09] ta [10:10] wgrant: fantastic, thanks for that [10:10] * wgrant knows enough Zope 3 to survive. [10:11] * bigjools hoped to never have to know that much Zope3 [10:13] * wgrant doesn't mind it. [10:24] Oh hooray, the global search field is going back down into the page footer [10:24] ah, so people can't use it ? [10:25] eh? [10:27] will people see it at all down at the bottom? [10:28] Well unless you're at the front page, the main reason to use the global search is because there's nothing on the current page relevant to where you actually want to be [10:29] My hypothesis (and it's only a hypothesis) is that you're more likely to come to that conclusion once you've scrolled through a page than when you're at the top [10:30] mpt: my feeling is that search at the top is great, but it should always be contextual; if you want global search hit the home page [10:30] or something like that [10:31] it would be interesting to make sure we can track the result of the change being made [10:31] There are quite a lot of pages with context-sensitive searches, e.g. project Bugs pages, distribution pages [10:33] If all pages had a single search field it would be hard to tell when someone was wanting context-sensitive results (e.g. show me only bug reports about only this project) and when they were wanting site-wide search results [11:02] Morning. [11:05] wgrant, thanks for your work on tracking down (and fixing!) those inline subscribing bugs. [11:05] mpt: thats true, which is why I suggest being always context sensitive and letting users request site wide [11:06] deryck: The second one wasn't at all as hard as I suspected, fortunately. [11:06] wgrant, yeah, I think once you understand the general subscribing process in js, all of these should be fairly easy to fix. [11:06] * deryck needs to look closer at each bug though [11:07] deryck: It took a while to work out how it all worked. [11:07] There's a bit of JS there... [11:07] indeed there is. [11:16] jtv: http://blog.launchpad.net/translations/screencast-importing-translation-templates-from-a-bazaar-branch [11:17] mrevell: listening to your voice now... [11:17] jtv: That's nice to know :) [11:17] mrevell: "you might notice that this is a copy of Barry Warsaw's I Have a Colon Full of Cookie project"..? [11:17] mrevell: do you expect many people to pick up on that? :) [11:18] jtv: Only in that there is the rather odd phrase "I have a colon full of cookie" in the pot. I think this was the tenth take after several Audacity crashes :) [11:19] mrevell: and how many retakes from starting to laugh when you said the phrase? [11:19] jtv: Heh, I was closer to tears after all the crashes [11:19] "oh good" [11:20] jtv: there's a factual error in that I say imports happen once a day but I'll fix that when I re-record it for the new UI [11:22] mrevell: you say "a few minutes instead of a day or two," though that's about the approval process rather than the import process. [11:22] jtv: Yeah, which I clarify later on [11:22] mrevell: where "clarify" is defined as "distort with lies and misinformation?" :-P [11:23] jtv: If the voiceover is actually misleading, I'll re-record. Do you want to give me a list of "bugs"? [11:24] mrevell: I just hit the point where you say "daily." I'll be sure to note anything else, but no other mistakes have caught my ear so far. [11:24] mrevell: these imports get triggered as soon as you push your changes. [11:25] jtv: I'll re-record. [11:25] jtv: I think it's an important fact to get right :) [11:26] mrevell: well it's not actually harmful since everything else including your demo very clearly says "a few minutes." So one could interpret the "daily" as "continually." === beuno_ is now known as beuno [11:27] mrevell: I've just watched the screencast, and I found it excellent! Just a comment/suggestion: in the last few seconds, when you are typing the translation in the textbox, it might be worth clicking on the radio button or on the arrow button of the original string to show people that they can be easily copied to the translation textbox with a mouse click. [11:27] jtv: The gods of audio recording seem to be smiling on me today, so it won't be too much effort to re-record. I like talking to myself anyway [11:28] mrevell: did danilo ask you about these screencasts btw? Joey wanted something like this as well. [11:28] Somebody want to help in #launchpad before things get too off course? === henninge_ is now known as henninge [11:29] mrevell: Note that nat/canonical/.. [11:30] dpm: Thanks for that suggestion! I have to confess I didn't even consider that. I'll mention that in the voiceover as that's easy to re-record and I think that's all we need for an extra value tip like that. [11:31] wgrant: Yeah, I'm still used to be able to recognise everyone's name :) [11:32] jtv: yeah, danilo pung me about this yesterday === intellec` is now known as intellectronica [12:34] jtv: I've fixed the import video. Now I'm going to record the export video. [12:36] mrevell: looking forward to that, for obvious reasons. :) I really liked getting the information in this format. [12:36] jtv: Is there any way to cheat/force the export? I guess I can wait until tomorrow to record the part where I go and look for the export in my branch, but joey might find this useful, as you said. [12:38] mrevell: you're not the first to ask... May be worth a new feature, though obviously we're not going to work on it very soon. [12:38] otoh for now the script performs so well that it looks like we might run it much more frequently. [12:39] jtv: Ah ok. So, there's no special "I'll buy you a pint jtv" button :) [12:39] jtv: When does the export occur? [12:40] mrevell: buying me a pint is fine, but getting an extra cron job approved & executed might not get it done much faster than just sitting and waiting. [12:40] * jtv looks up the times [12:40] :) [12:41] mrevell: between 03:00 and 04:00 UTC [12:41] or BST, if that's what the logs are in. [12:41] jtv: Cool, thanks === danilos is now known as danilo-food [13:26] gmb: If I want to fix bug #415165, do I have to change all sites that set it to use the new method? Or can I just set the field readonly and export a mutator, to only protect the webservice side? === mrevell is now known as mrevell-lunch [13:37] * gmb looks at the bug [13:37] Ah, right. [13:38] wgrant: The problem specifically effects anything that uses the webservice, so exporting the mutator should be sufficient. You can then file a follow-up bug to make everything else use the new method, but that's less urgent. [13:43] gmb: Thanks, I was just wondering if I would be committing Evil by not changing the rest. [13:44] wgrant: Nah - what's there already has worked up until this point. [13:44] (And as I said, what's there already for non-webservice stuff isn't all that broken) === henninge_ is now known as henninge [13:49] jtv, danilo-food: wanne take a look at my TranslatableMessage draft? [13:49] jtv: https://pastebin.canonical.com/21250/ [13:49] henninge: looking... [13:51] jtv: actually I am thinking of even more high-level methods. [13:51] jtv: like "getAllTranslations" [13:52] henninge: a small note... names like is_empty and is_imported don't really mesh with the choice of Translat*able*Message. [13:52] ;-) [13:52] sinzui said: No.one menu must be bound to the oject, the other to the view, so you must pass each so that when we use nearest(INavigationMenu) we get the right menu [13:52] jtv: well they are really "(Re)TranslatableMessage) [13:52] henninge: I think you've made a good start with these low-level things; this should not become a 2-year project after all. :-) [13:53] jtv: meaning [13:53] ? [13:54] henninge: about the names, I mean that is_empty etc. should be something like current_translation_is_empty etc. to reflect that it's the translation, not the POTMsgSet, that is empty (or whatever). [13:54] jtv: ok, no problem [13:55] henninge: about the other thing, I mean don't worry too much about pulling in more functionality; you'll risk making more changes than needed and complicating things. [13:55] sinzui: nearest() seems like a rather magical (and error prone) way to find the menu. why is it not explicit? [13:56] barry: You are using the zope, This is how all menus work [13:56] jtv: You mean, the rest can be done in the view? [13:57] henninge: I'm not making any predictions, just saying be conservative in what you move in here because it's going to pile up anyway. :) [13:57] sinzui: my point is, i guess, that we should do better [13:57] barry: if it was very explicit, people would be making menus everywhere and the pages would be a mess. NavigateMenus were design to work with two scenario, items about the object and items about the objects content [13:57] jtv: I see. [13:58] barry: I loath to change the way something has worked for 18 months [13:58] barry: remember that lots of pages are using them. [13:59] sinzui: then we should be building a better mechanism that new pages would use. but i'll drop this for now. [14:01]