[Launchpad-dev] This page allows you to...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis Hovey wrote on 10/01/11 15:00: ... https://dev.launchpad.net/LEP/DerivativeDistributions#Mockups +newseries This page allows you to add a new distribution series In https://dev.launchpad.net/UserInterfaceWording a few years ago, I proposed that no Launchpad page should intentionally contain the phrase this page. The window in which you are reading e-mail right now almost certainly doesn't say this window allows you to read e-mail. In the same way, the purpose of a page should be obvious from the contents of the page. When a form page has a one-sentence introduction, it's easy to briefly hint at the purpose of, consequences of, and/or next step after the task, without referring to the page itself. In this case, for example: Once you've registered a distribution series, it can be initialized with packages from a parent series. - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk09t/EACgkQ6PUxNfU6ecr1ggCdFgcR1GAo0P0GyXcP9RgIleQX oLMAnjne4trlhgA5j4j/W1kse2h3c5NP =v8S2 -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] PythonStyleGuide reduced
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-01-21 05:59 PM, Henning Eggers wrote: Robert, Brad and myself reduced the style guide as follows. Please comment. https://dev.launchpad.net/PythonStyleGuide?action=diffrev2=20rev1=18 https://dev.launchpad.net/PythonStyleGuide?action=diffrev2=20rev1=18 I think we should keep Importing a module should not have side effects. One of the libraries used by launchpadlib for storing passwords does this, as does lp.codehosting, so we can't assume people will avoid it. Other than that, I think this looks good. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk09mhYACgkQ0F+nu1YWqI2KHQCggSxfvzBNsFxXGr9QIc2LpLE9 v+wAn0FjqgFEveBaKMqHjhpyEeY+duwU =SxIg -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] Performance Characteristics of Codebrowse
On Thu, 20 Jan 2011 22:42:57 -0800, Max Kanat-Alexander mka...@bugzilla.org wrote: On 01/20/2011 09:56 PM, Max Kanat-Alexander wrote: I'm also going to be doing some profiling of ChangeLogUI to see if it can be faster, but I'm not certain that will be possible. Okay, yes, some quick profiling shows that the only broad performance improvements we're going to see are: * Getting history_db live on codebrowse. +1. I suck for not having got this done before I left the launchpad team... * Switching to a faster templating engine (I recommend Mako) Can mako stream output though? Much as I hate simpletal, not buffering the output in RAM was an important change when I made it... Cheers, mwh ___ 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] Performance Characteristics of Codebrowse
On Tue, Jan 25, 2011 at 8:00 AM, Michael Hudson-Doyle michael.hud...@canonical.com wrote: * Switching to a faster templating engine (I recommend Mako) Can mako stream output though? Much as I hate simpletal, not buffering the output in RAM was an important change when I made it... We're moving LP to chameleon (https://dev.launchpad.net/LEP/Chameleon) - would that be faster still stream? -Rob ___ 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] YUI upgrades (and Python upgrades)
Hi Robert. The people with more YUI 3 experience on my team have warned me that jumps from one big version of YUI to the next--say, 3.1 to 3.2--can be very disruptive. They compared them to Python major dot releases. 1) Are you responsible for scheduling the YUI upgrades? If not, and no one is officially, I suggest that we find someone to take that responsibility. 2) For whoever will be responsible, what will our upgrade policy be? I'm interested in how it will be announced to the team and what kind of lead time we should expect. Perhaps others will mention other things to consider. As you know, I'm also interested in the Python upgrade story, and coordination for a smooth transition to the next LTS. I expect the Python 2.7 migration is just another feature card that needs to have its scheduling negotiated with Jono? Thank you, Gary ___ 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] YUI upgrades (and Python upgrades)
On Tue, Jan 25, 2011 at 10:01 AM, Gary Poster gary.pos...@canonical.com wrote: Hi Robert. The people with more YUI 3 experience on my team have warned me that jumps from one big version of YUI to the next--say, 3.1 to 3.2--can be very disruptive. They compared them to Python major dot releases. 1) Are you responsible for scheduling the YUI upgrades? If not, and no one is officially, I suggest that we find someone to take that responsibility. I don't have it on my 'things to check plate'. I could add it, or we can do it when useful in the same way we upgrade our zope dependencies - that is when someone wants something, we check the impact and do the upgrade. 2) For whoever will be responsible, what will our upgrade policy be? I'm interested in how it will be announced to the team and what kind of lead time we should expect. Perhaps others will mention other things to consider. I don't know :) What do you think we should do here? My initial thought is that staying up to date on YUI has significant benefits for us. As you know, I'm also interested in the Python upgrade story, and coordination for a smooth transition to the next LTS. I expect the Python 2.7 migration is just another feature card that needs to have its scheduling negotiated with Jono? I think its reasonable to treat problematic dependency changes as feature cards for the feature queue. Not all important-dependency changes will be problematic or big enough to need a timeslot reserved like that. -Rob ___ 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] Performance Characteristics of Codebrowse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/24/2011 1:07 PM, Robert Collins wrote: On Tue, Jan 25, 2011 at 8:00 AM, Michael Hudson-Doyle michael.hud...@canonical.com wrote: * Switching to a faster templating engine (I recommend Mako) Can mako stream output though? Much as I hate simpletal, not buffering the output in RAM was an important change when I made it... We're moving LP to chameleon (https://dev.launchpad.net/LEP/Chameleon) - would that be faster still stream? -Rob AIUI Chameleon is the same template language as simpletal, which is also a significant win (not having to learn a new syntax). As for (not)buffering, I would think that would really depend on the specific page. I guess Annotation/View is going to show full content, but the bzr side still loads up the whole thing anyway. Is there a specific page you have in mind? John =:- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk097DgACgkQJdeBCYSNAANksgCfUQTMXlqeILOjV2Ap/uu5WcI+ iJAAn38iys7AtQC0mVzuvYFYTeXzdPJZ =JOZE -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] Performance Characteristics of Codebrowse
Max, one more specific thing: the feature of showing file contents without annotation but escaped into html. (That is to say, not the full unrestricted /raw/.) Where does that stand? -- 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] YUI upgrades (and Python upgrades)
OK, thank you, Francis. Deryck, could you keep us apprised of when you think the upgrade might happen (assuming you don't run into extra fun like last time)? Robert, I'm waiting to see if others have better replies that I would have to your questions. :-) Thanks Gary On Jan 24, 2011, at 4:24 PM, Francis J. Lacoste wrote: Hi, Deryck is actually looking at that one right now. (He started last week.) He sheparded the last one, so decided to do this one right now since it's pretty fresh in his head. Sidnei said that this upgrade was pretty painless compared to the previous ones. -- Francis J. Lacoste francis.laco...@canonical.com On January 24, 2011, Robert Collins wrote: On Tue, Jan 25, 2011 at 10:01 AM, Gary Poster gary.pos...@canonical.com wrote: Hi Robert. The people with more YUI 3 experience on my team have warned me that jumps from one big version of YUI to the next--say, 3.1 to 3.2--can be very disruptive. They compared them to Python major dot releases. 1) Are you responsible for scheduling the YUI upgrades? If not, and no one is officially, I suggest that we find someone to take that responsibility. I don't have it on my 'things to check plate'. I could add it, or we can do it when useful in the same way we upgrade our zope dependencies - that is when someone wants something, we check the impact and do the upgrade. 2) For whoever will be responsible, what will our upgrade policy be? I'm interested in how it will be announced to the team and what kind of lead time we should expect. Perhaps others will mention other things to consider. I don't know :) What do you think we should do here? My initial thought is that staying up to date on YUI has significant benefits for us. As you know, I'm also interested in the Python upgrade story, and coordination for a smooth transition to the next LTS. I expect the Python 2.7 migration is just another feature card that needs to have its scheduling negotiated with Jono? I think its reasonable to treat problematic dependency changes as feature cards for the feature queue. Not all important-dependency changes will be problematic or big enough to need a timeslot reserved like that. -Rob ___ 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 ___ 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] Performance Characteristics of Codebrowse
On 01/24/2011 01:16 PM, John Arbash Meinel wrote: Can mako stream output though? Much as I hate simpletal, not buffering the output in RAM was an important change when I made it... http://www.makotemplates.org/docs/filtering.html#buffering It sounds like even if the buffer doesn't stream directly, it wouldn't be hard to replace it with one that does. We're moving LP to chameleon (https://dev.launchpad.net/LEP/Chameleon) - would that be faster still stream? It certainly sounds like it would be faster. AIUI Chameleon is the same template language as simpletal, which is also a significant win (not having to learn a new syntax). Mako is designed to look almost exactly like normal Python, which would actually, for most people, be *less* syntax to learn. For example: http://www.makotemplates.org/docs/syntax.html#control-structures Also, I would say that the syntax of SimpleTAL is difficult to read, particularly because so much happens inside of attributes. There are some advantages to SimpleTAL, though, such as enforced HTML validation and simple HTML escaping. As for (not)buffering, I would think that would really depend on the specific page. I guess Annotation/View is going to show full content, but the bzr side still loads up the whole thing anyway. Is there a specific page you have in mind? The View/Annotation page actually responds significantly faster when it can stream than when it doesn't. So streaming would be a useful and important feature. -Max -- http://www.bugzillasource.com/ Competent, Friendly Bugzilla, Perl, and IT Services ___ 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] Performance Characteristics of Codebrowse
On 01/24/2011 01:26 PM, Martin Pool wrote: Max, one more specific thing: the feature of showing file contents without annotation but escaped into html. (That is to say, not the full unrestricted /raw/.) Where does that stand? That already exists on launchpad today. That's ViewUI in the original email. -Max -- http://www.bugzillasource.com/ Competent, Friendly Bugzilla, Perl, and IT Services ___ 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] PythonStyleGuide reduced
Am 24.01.2011 08:26, schrieb Aaron Bentley: I think we should keep Importing a module should not have side effects. One of the libraries used by launchpadlib for storing passwords does this, as does lp.codehosting, so we can't assume people will avoid it. We removed stuff that we felt is general software engineering knowledge that everyone working here should know. Side effects are always bad, that is not Launchpad-specific. Are we expecting too much possibly? Henning ___ 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] Performance Characteristics of Codebrowse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As for (not)buffering, I would think that would really depend on the specific page. I guess Annotation/View is going to show full content, but the bzr side still loads up the whole thing anyway. Is there a specific page you have in mind? Yeah, it was the annotation pages that tended to get very large (I think some were ~70 megs of HTML). Perhaps it's better now, but it made a difference on LP when we changed to streaming. Cheers, mwh That seems worthy of taking a closer look at the raw HTML to see if there are ways to avoid being that verbose. John =:- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0+DosACgkQJdeBCYSNAAMicACgyY3lX0MkSNqO8EAfwTLyPFqT kQIAnic3wu7Y43Ho0QxCD+avZS54iSv9 =ryhG -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] PythonStyleGuide reduced
On 25 January 2011 09:57, Henning Eggers henning.egg...@canonical.com wrote: Am 24.01.2011 08:26, schrieb Aaron Bentley: I think we should keep Importing a module should not have side effects. One of the libraries used by launchpadlib for storing passwords does this, as does lp.codehosting, so we can't assume people will avoid it. We removed stuff that we felt is general software engineering knowledge that everyone working here should know. +1, in fact I think you should also omit things that are general Python knowledge. (Things that are general Zope knowledge etc perhaps should be included or at least pointed to, since not everybody will know them.) Side effects are always bad, that is not Launchpad-specific. Are we expecting too much possibly? -- 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] notes towards async api clients
I had a bit of a go at this over the weekend. It is gratifyingly fast compared to what I expect to see with launchpadlib clients, just through doing fewer requests and not unnecessarily blocking on them. I like that a lot. The code is in http://launchpad.net/wrested and lp:wrested. For instance: ./wrestler.py https://api.launchpad.net/devel/bugs/1 ./wrestler.py https://api.launchpad.net/devel/bzr/'?ws.op=searchTasks' (Try it!) It's early days but I really like how it's shaping up. I think it is less error-prone than the approach taken by txrestfulclient, because you never get half-initialized objects: if you have the resource, it's valid. I'm finding it also nicer to work with than launchpadlib because you never get unexpected pauses: all network io is explicit. It seems to me it would be healthy for Launchpad for people to be looking at what the actual http interface is, rather than using a black-box client. https://help.launchpad.net/API/Hacking was a great resource (thanks.) The basic approach is that you ask for an object and get a deferred, which will eventually deliver the object you requested. For collections, you pass a consumer which will be fed objects as they arrive. I can see this fitting very well with what's described in https://dev.launchpad.net/LEP/WebservicePerformance. I am trying to keep a separation between Launchpad-specific policy and REST in general; though I'm not quite sure yet how many conventions are standard and how many Launchpad has made up for itself. It has a nerd-oriented gtk explorer test harness: http://www.flickr.com/photos/mbp_/5386185146/ which can open an arbitrary URL, click through links to other objects, and stream reads of collections, including very large collections like all the bugs. All these capabilities are of course also exposed in the library api. It should do, but doesn't yet: * authenticated requests * socket reuse * caching * anything to do with the WADL * (a bunch of other things in the TODO) I have mixed feelings about WADL. As a systematic way of documenting an API, and something from which you can produce apidoc html or whatever it's fine. As something applications will read _at run time_ it seems a bit strange: the application will be written assuming particular APIs are present and if they are not, or if other APIs do turn out to be present, the application is not likely to suddenly make use of them. An application that did want to cope with differing server capabilities would probably be better off just sending requests and coping with errors. But perhaps an exception to this is an explorer-type application which does want to show all the methods you, the interactive user, could possibly call if you wanted to. That leads me to think it should be something applications can opt in to, if they want to introspect the interface. It does seem wrong to me that applications should need to download over a megabyte of data when it can't really change their behavior. That leaves open the question of how a client ought to call methods, like say https://api.launchpad.net/devel/bzr/?ws.op=searchTasks. It would be ugly to have random client apps hardcode that. (It's also ugly to have, as at present in launchpadlib, them necessarily fetch https://api.launchpad.net/devel/bzr/ first when they don't want to know about the product itself, only its bug tasks.) (Incidentally, I wonder why we don't have eg a bug_tasks_collection_link on products, which seems a bit more in keeping with a REST-ish style.) So it's quite fun and I intend to continue. If someone wants to talk about it I'd like that too. -- 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] notes towards async api clients
On Tue, 25 Jan 2011 12:10:43 +1100, Martin Pool m...@canonical.com wrote:
I had a bit of a go at this over the weekend. It is gratifyingly fast
compared to what I expect to see with launchpadlib clients, just
through doing fewer requests and not unnecessarily blocking on them.
I like that a lot.
The code is in http://launchpad.net/wrested and lp:wrested.
For instance:
./wrestler.py https://api.launchpad.net/devel/bugs/1
To be fair I believe lplib would perform approximately as well if you
just did lp.load('https://api.launchpad.net/devel/bugs/1').
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
Re: [Launchpad-dev] notes towards async api clients
On Tue, 25 Jan 2011 12:10:43 +1100, Martin Pool m...@canonical.com wrote: So it's quite fun and I intend to continue. If someone wants to talk about it I'd like that too. Thanks for this, it's good to see things progressing on this front. I think that this would make a great bottom layer for a twisted LP client library. I think that if we were to merge this and txrestfulclient then we would have the best of both worlds. I think this is a better building-block way to go, but most developers won't want to hardcode URLs everywhere, so putting it together with the higher-level stuff in txrestfulclient (which deals with WADL etc.) would allow developers to work at the level that they want. 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
