Re: [Launchpad-dev] do we have guidelines on what goes in model, and what in browser?
On Sun, 2010-12-12 at 20:28 +0100, Jelmer Vernooij wrote: On Mon, 2010-12-13 at 08:17 +1300, Robert Collins wrote: I've looked on the dev wiki, but found no useful pages in a full text search for 'model browser' :) The reason I ask, is that it might make things a little simpler for reviewers and developers if there were some generally expected guidelines. Not that the guidelines are large: the core of it is 'rendering and marshalling code should be in browser/, querying and mutating code should be in model/'. The reasons for suggesting that as the guideline: - code in the model can be exposed on the API - code in the model can be declaritively secured - we don't need to do html rendering and other browser-connection logic in the API so separating out 'could be used in the API' into model/ nicely decouples the two - and allows testing the core functionality without html parsing etc. However, perhaps I'm fundamentally confused here and we already have strong guidelines - perhaps ones that disagree with this proposal - that I overlooked? In which case, point me at em! As far as I know those are the guidelines we already have, at least that's how it was explained to me when I first started hacking on Indeed. browser code. IIRC the import fascist also used to complain about importing from database modules directly into browser code. The reason the fascist does that is because browser code must use only the secured utilities to get access to model code. That's to ensure browser code can't get access to non-security-proxied model code. This should certainly be documented, but I don't think it's directly related to what Robert is proposing? -- Guilherme Salgado https://launchpad.net/~salgado signature.asc Description: This is a digitally signed message part ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] do we have guidelines on what goes in model, and what in browser?
On Sunday 12 December 2010 19:17:48 Robert Collins wrote: Not that the guidelines are large: the core of it is 'rendering and marshalling code should be in browser/, querying and mutating code should be in model/'. I've always worked on the basis of Can this code be re-used outside of the browser class? If the answer is no, it stays in the view class, otherwise it goes to the model. The model is not necessarily always the right place for that code, but we don't really have a clear plan on where else to put stuff right now. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Phasing in the Architecture Design Metrics into our reviews
On Dec 8, 2010, at 10:34 , Aaron Bentley wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/08/2010 09:14 AM, Brad Crittenden wrote: Tests for a class should complete in under 2 seconds. If they aren't, spend at least a little time determining why. To incorporate this metric into your reviews you'll obviously need to run the tests. If a test is brand new then you can just evaluate the timing. Modifications to existing tests should be compared with before and after timings. So reviewers, either download the code being reviewed and run the tests yourself or ask the developer for comparative timings. Start the conversation. You say that we can incorporate this metric by checking the timing of new and modified tests, but the metric is about all tests for a class. In order to derive the times for all tests for the class from the timing of new and modified tests, we would have to already know the cumulative time of tests for the class. We don't have that, and can't easily generate it, because execution times will vary depending on developer machines. I think you're proposing a new metric instead of incorporating the one you quote. Could you please spell out your new metric, so that I can consider it during my reviews? Aaron Hi Aaron, I tried to explain my intentions during the reviewers meeting last week but clearly failed for you. After much discussion I thought Julian's summary was good: [15:19] bigjools can we paraphrase this as please review how long your tests are taking As Jono later indicated, we probably don't want to suggest a lot of non-intuitive changes for the sake of speeding up the test as we'll have major changes to our test infrastructure in the near future. I am asking that developers and reviewers take test timing into consideration. Easy things such as the example I cited of creating a view directly rather than using the user browser is a big speed up when applicable. --Brad ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Phasing in the Architecture Design Metrics into our reviews
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10-12-13 09:23 AM, Brad Crittenden wrote: On Dec 8, 2010, at 10:34 , Aaron Bentley wrote: I think you're proposing a new metric instead of incorporating the one you quote. Could you please spell out your new metric, so that I can consider it during my reviews? I tried to explain my intentions during the reviewers meeting last week but clearly failed for you. After much discussion I thought Julian's summary was good: [15:19] bigjools can we paraphrase this as please review how long your tests are taking Thanks, but I'm looking for a guideline I can use as a reviewer to say your tests are taking too long or your tests are astoundingly fast-- please share your secrets with the mailing list. Without numbers, I can't do that. Robert's metric had numbers, so it was at least theoretically possible to use that way. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0GL6IACgkQ0F+nu1YWqI3eegCcDmze2hR04WGHgJTKgAc9dRVb TjcAn37DJf9oVRsUz2BYVvzVq39p1VbG =XGFP -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Phasing in the Architecture Design Metrics into our reviews
Thanks, but I'm looking for a guideline I can use as a reviewer to say your tests are taking too long or your tests are astoundingly fast-- please share your secrets with the mailing list. Without numbers, I can't do that. Hi Aaron, Reviews are a discussion not simply enforcement of rules. I'd have no problem saying Wow, your new test provides great coverage but seems to be really slow. Let's see if we can speed it up. --Brad Robert's metric had numbers, so it was at least theoretically possible to use that way. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Phasing in the Architecture Design Metrics into our reviews
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10-12-13 09:45 AM, Brad Crittenden wrote: Thanks, but I'm looking for a guideline I can use as a reviewer to say your tests are taking too long or your tests are astoundingly fast-- please share your secrets with the mailing list. Without numbers, I can't do that. Hi Aaron, Reviews are a discussion not simply enforcement of rules. I'd have no problem saying Wow, your new test provides great coverage but seems to be really slow. Let's see if we can speed it up. Certainly, reviews are not merely enforcement of rules. But I can't say Wow, your new test provides great coverage but seems to be really slow. Let's see if we can speed it up. until I have a definition of slow. Without numbers, I can't do that. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0GM2QACgkQ0F+nu1YWqI3H/wCeIEIhvDxXYbYDIK38vX4ombsT jekAn3wMxHkjwvDumTnWnxYiJQkAmdPS =5GRT -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
[Launchpad-dev] Webservice performance
Hi, First off, let me say thanks for the webservice. Having it there has enabled a lot of things, and it is very much a positive in my eyes. However, I have a short story to tell you. Ubuntu has used the work items tracker for a few releases now. This scrapes the blueprints tracker, and pulls out workitems that are in the whiteboards, as well as bug links etc. and graphs them over time. http://people.canonical.com/~platform/workitems/natty/all-ubuntu-11.04-beta.html Due to the fact that blueprints weren't exported on the API, it has always done this by screenscraping, using a set of regexes to pull out what it wants from each page. This has made it hard to do certain things (such as look at dependencies, which are only represented in graphical form on the blueprint page), so recently Guilherme and I exported an API for blueprints. I then ported the work items tracker to use this API, which was quick to do. However, when testing it we noticed that it was about 10% slower than the old code. This suprised me, as I was expecting a performance increase, due to the batching that the webservice gives you when dealing with collections, and possible small increases from the appservers having to do less work (rendering HTML etc) and not using regexes as much due to having attributes already defined. When looking in to why, I turned on tracing of the HTTP requests that were being made, and it was quickly apparent what the problem was. The code wants to associate blueprints with people, so for each of (drafter, assignee, approver) it gets their user id. drafter = bp.drafter.name assignee = bp.assignee.name approver = bp.approver.name What happens here is that there is an extra round trip on each of these lines, to follow the link in the blueprint representation, get the person representation, and to pull out their name. These round trips quickly negate the benefit of the batching, as rather than 1 round trip per blueprint that the old code does, we now do 3 (plus one for every page of blueprints). Even with caching, the code still does the round trips to ensure that the cache is up to date (when we don't really care in this case, we're not realtime, and changes while the code is running can actually be harmful as it is tricky to code defensively against that) I was able to confirm this by writing a hacky function that given a link to a person tells you there user id by parsing the URL, and the code then showed the expected speedup over the old code. While this isn't a huge issue, I'm disappointed that the API is slower than screen scraping, and it isn't much of an advert for the API. Please do something about this. Having a much better performing API would open up the possiblilities of a whole new swathe of applications using it, much like adding the API in the first place did. Thanks, James ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
[Launchpad-dev] Lost revision r11685
I just discovered that my test refactoring for mailman/monkeypatches/lpsize are missing. The fix for exceeding The DB's max size is missing. https://code.launchpad.net/~wgrant/launchpad/bug-655614-disabled-arch-indices rolled back my changes. I am going to remerge my branch so that the oops does not reappear. -- __Curtis C. Hovey_ http://launchpad.net/ signature.asc Description: This is a digitally signed message part ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Launchpad Projects Merge Preview
Hi Curtis, On December 13, 2010, Curtis Hovey wrote: On Mon, 2010-12-13 at 12:16 -0500, Francis J. Lacoste wrote: BUGTASKS Maybe 'launchpad-web' THEN 'lp-web could be 'launchpad-web' THEN 'lp-app because most of the bugs that were moved are issues in lp.app. 'lp-foundations' could be 'lp-services'. This is not necessarilly accurate, but could be true when launchpad/webapp is dismantled. The migration script would then be mapping projects top lib/lp/module I see those tags as temporary. I don't think we should try to give them more meaning than they have. OFFICIAL BUG TAGS They were not updated Only the Launchpad project has official bug tags. I don't think we should make these tags official since their only purpose is as a migration artefact. STRUCTURAL SUBSCRIPTIONS AND ANSWER CONTACT FOR They were not updated. Will there be an announcement tell users to update them to /launchpad? Yes, we can mention that in the announcement. DELETE BUGTASKS This might be a chance to delete the unwanted series tasks. Looking at this example bug, I see another issues too when looking at the link. https://bugs.staging.launchpad.net/launchpad/+bug/201792 Good point, I'll add a delete for all of those. (There is only 1 AFAICT) What is this: https://staging.launchpad.net/old-lp-bugs ? Why does the bugtask link to it? I am sure most users will get a 404 They would, that's because I didn't handle productseries linkage. UPDATE BUGTASKS Looking at https://bugs.staging.launchpad.net/launchpad/+bug/201792 The first bugtask says Launchpad Bugs, but links to /launchpad. This might be because of bugTask.bugtargetdisplayname which uses targetnamecache. I thought there was a bug about removing the cache...use the bugTask.target instead...but I do not see it anymore? I modified the script to handle that. Staging should be updated soon. -- Francis J. Lacoste francis.laco...@canonical.com signature.asc Description: This is a digitally signed message part. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Launchpad Projects Merge Preview
On 13 December 2010 19:54, Francis J. Lacoste francis.laco...@canonical.com wrote: Hi Curtis, On December 13, 2010, Curtis Hovey wrote: On Mon, 2010-12-13 at 12:16 -0500, Francis J. Lacoste wrote: BUGTASKS Maybe 'launchpad-web' THEN 'lp-web could be 'launchpad-web' THEN 'lp-app because most of the bugs that were moved are issues in lp.app. 'lp-foundations' could be 'lp-services'. This is not necessarilly accurate, but could be true when launchpad/webapp is dismantled. The migration script would then be mapping projects top lib/lp/module I see those tags as temporary. I don't think we should try to give them more meaning than they have. OFFICIAL BUG TAGS They were not updated Only the Launchpad project has official bug tags. I don't think we should make these tags official since their only purpose is as a migration artefact. Malone has some official tags, for example 'bugwatch' along with various 'story-*' tags (because tab-completion is cool and we should do more of it). Will those be migrated (or have I misunderstood and they've been migrated already)? -- Graham Binns | PGP Key: EC66FA7D http://launchpad.net/~gmb ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Launchpad Projects Merge Preview
On Mon, 2010-12-13 at 14:54 -0500, Francis J. Lacoste wrote: DELETE BUGTASKS This might be a chance to delete the unwanted series tasks. Looking at this example bug, I see another issues too when looking at the link. https://bugs.staging.launchpad.net/launchpad/+bug/201792 Good point, I'll add a delete for all of those. (There is only 1 AFAICT) I know of 3, but I do not know how to search for more. https://bugs.launchpad.net/malone/1.2 What is this: https://staging.launchpad.net/old-lp-bugs ? Why does the bugtask link to it? I am sure most users will get a 404 They would, that's because I didn't handle productseries linkage. -- __Curtis C. Hovey_ http://launchpad.net/ signature.asc Description: This is a digitally signed message part ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Launchpad Projects Merge Preview
On December 13, 2010, Curtis Hovey wrote: On Mon, 2010-12-13 at 14:54 -0500, Francis J. Lacoste wrote: DELETE BUGTASKS This might be a chance to delete the unwanted series tasks. Looking at this example bug, I see another issues too when looking at the link. https://bugs.staging.launchpad.net/launchpad/+bug/201792 Good point, I'll add a delete for all of those. (There is only 1 AFAICT) I know of 3, but I do not know how to search for more. https://bugs.launchpad.net/malone/1.2 Actually, there were 101 of those. (My original query used the original project names, which were not in the DB anymore.) -- Francis J. Lacoste francis.laco...@canonical.com signature.asc Description: This is a digitally signed message part. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Launchpad Projects Merge Preview
On December 13, 2010, Graham Binns wrote: On 13 December 2010 19:54, Francis J. Lacoste francis.laco...@canonical.com wrote: Hi Curtis, On December 13, 2010, Curtis Hovey wrote: On Mon, 2010-12-13 at 12:16 -0500, Francis J. Lacoste wrote: OFFICIAL BUG TAGS They were not updated Only the Launchpad project has official bug tags. I don't think we should make these tags official since their only purpose is as a migration artefact. Malone has some official tags, for example 'bugwatch' along with various 'story-*' tags (because tab-completion is cool and we should do more of it). Will those be migrated (or have I misunderstood and they've been migrated already)? That's another case where I used the old names and didn't find anything. There are actually 91 offical bug tags that should made official into the Launchpad project. I've added that to the SQL migration (should be live on staging shortly). Cheers -- Francis J. Lacoste francis.laco...@canonical.com signature.asc Description: This is a digitally signed message part. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Launchpad Projects Merge Preview
On 14 December 2010 11:03, Max Bowsher m...@f2s.com wrote: On 13/12/10 17:16, Francis J. Lacoste wrote: Hi everyone, Please browse https://bugs.staging.launchpad.net/launchpad for a preview of the future. Staging got rid of the following sub projects: blueprint, launchpad-answers, launchpad-code, launchpad-foundations, launchpad-registry, launchpad-web, malone, rosetta and soyuz. The projects were deactivated. (The launchpad-* aliases will be added on production.) All bugs, questions and faqs were reassigned to the one and only one launchpad project. There's probably a good reason for doing all this, and it may even have been mentioned on this list at some point, but speaking as someone on the periphery of LP development, this feels like a negative step. If I wanted to search for whether a bug was already reported, I used to be able to immediately focus in on just the code, or soyuz, or malone, etc. I would suggest that some mention of this reorganization should probably occur on the Launchpad Blog before it hits production. I think this is a positive step for Launchpad. * time is wasted at the moment re-sorting bugs * other projects need ways to group bugs within a single code base; launchpad shouldn't cheat by using multiple projects * work is underway (iirc) on subscribe-to-tag etc I do agree with Max this ought to be advertised before it's done. There are people (well, at least me) who have things bookmarked, who are subscribed to bugs in particular apps, etc. A one or two paragraph blog post would do, and we don't need to enter into bikeshedding. -- Martin ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Launchpad Projects Merge Preview
On 14/12/10 02:07, Martin Pool wrote: On 14 December 2010 11:03, Max Bowsher m...@f2s.com wrote: On 13/12/10 17:16, Francis J. Lacoste wrote: Hi everyone, Please browse https://bugs.staging.launchpad.net/launchpad for a preview of the future. Staging got rid of the following sub projects: blueprint, launchpad-answers, launchpad-code, launchpad-foundations, launchpad-registry, launchpad-web, malone, rosetta and soyuz. The projects were deactivated. (The launchpad-* aliases will be added on production.) All bugs, questions and faqs were reassigned to the one and only one launchpad project. There's probably a good reason for doing all this, and it may even have been mentioned on this list at some point, but speaking as someone on the periphery of LP development, this feels like a negative step. If I wanted to search for whether a bug was already reported, I used to be able to immediately focus in on just the code, or soyuz, or malone, etc. I would suggest that some mention of this reorganization should probably occur on the Launchpad Blog before it hits production. I think this is a positive step for Launchpad. * time is wasted at the moment re-sorting bugs * other projects need ways to group bugs within a single code base; launchpad shouldn't cheat by using multiple projects * work is underway (iirc) on subscribe-to-tag etc I do agree with Max this ought to be advertised before it's done. There are people (well, at least me) who have things bookmarked, who are subscribed to bugs in particular apps, etc. A one or two paragraph blog post would do, and we don't need to enter into bikeshedding. Including a The new way to search bugs just within the Soyuz component of Launchpad is ... (etc.) in the blog post would likely make it a lot less likely to make people think negatively about the change. Max. signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
