On Thu, Dec 17, 2009 at 11:59 PM, Gary Poster <[email protected]> wrote: > > On Dec 16, 2009, at 8:01 PM, Jonathan Lange wrote: > >> On Thu, Dec 17, 2009 at 1:52 AM, Francis J. Lacoste >> <[email protected]> wrote: >>> On December 15, 2009, Jonathan Lange wrote: >>>> On Wed, Dec 9, 2009 at 6:28 PM, Jonathan Lange <[email protected]> wrote: >>>>> Hello, >>>>> >>>>> How can I help release launchpadlib? There's been some great stuff >>>>> added since the 1.5.3 release in October, and I'd love to use it in >>>>> applications that only allow depending on released things. I'd be >>>>> happy to do whatever is required; I simply don't know what that is. >>>>> >>>>> Also, for future reference, does launchpadlib follow a fixed release >>>>> schedule? >>>> >>> >>> It doesn't. >>> >>> Currently, it's released whenever we need to take advantage of a bug fix / >>> new >>> features in Launchpad. >>> >>> Since nobody really develops that application. I don't think it makes sense >>> to >>> have a fixed schedule. >>> >> >> Maybe, maybe not. I know I'd probably submit more patches to >> launchpadlib if it felt more active. That might be more of a function >> of the review queue than the release cycle, though. > > When you talk about "launchpadlib" development and releases, I think you > actually are referring to the collection of libraries that provide this > functionality: > > - lazr.restful (server-side implementation) > - wadlib (parses WADL, which our server generates; dependency of...) > - lazr.restfulclient (the client implementation) > - launchpadlib (a thin wrapper over lazr.restfulclient) >
In this case, I was actually referring to launchpadlib. > As a collection, these libraries are in fact under active development, > primarily by Leonard. His holiday schedule has slowed the releases down > significantly--as well as a recent security change that Leonard wanted to > shake out before he made a release--but otherwise it is as fast as his > development requires, which actually is usually at a pretty good clip. I'd agree. I'm genuinely impressed with the recent changes to the suite of API libraries -- launchpadlib in particular. That's why I'm so keen for a release :) > > All that said, it's also worth acknowledging that there have been some > contributions stuck in the review queue lately. To some degree that's again > tied to Leonard's holiday schedule, but I still suspect that we legitimately > need to improve. I'll ping Leonard about the queue today, before he returns > to holiday vacation. I didn't mean to criticise in my earlier email, but looking over it I can see that I did it anyway -- sorry. I guess what I meant was that launchpadlib et al are now growing a community of users who are also developers. Many of them are fixing perceived deficiencies in the library by writing wrapper code. I don't think it's as much a matter of improving as maybe a change of mindset. Of course, I might well be mistaken here -- it's really hard to know someone else's mindset after all :) > >> It's also worth noting that there's an increasing user-base for >> launchpadlib, and they are beginning to demand more sophisticated >> things from it. > > Leonard is in the middle of a number of interesting changes to the webservice > right now. These will emerge over the course of the next six months. > > - He is adding versioning, so we can do what had been planned for a long > time: declare the "beta" webservice frozen (or at least backwards compatible > forevermore, TBD), declare "1.0" to be beta, and have a process for making > backwards incompatible changes in the future. This is due in February. > We'll describe this in the future, but generally: > * released webservice versions will be tied to Ubuntu releases, and we > will support legacy Ubuntu releases using the mechanism; and > * we will propose that our own JS webservice use always be tied to the > evolving "trunk" of the API. This is excellent news. > - Once we have versioning, he plans to introduce changes that will allow the > launchpadlib API (that is, the one exposed by our webservice, and defined in > Launchpad itself) to become more uniform. Other "more sophisticated things" > may also want to be added in a backwards-incompatible manner. > - We collectively have plans to try to leverage our cacheing experiments > (e.g., memcached) to cache etag values and JSON representations. This is > risky (in the since that we might discover it is too complex or has another > show-stopper), but has a good chance of speeding up the webservice > significantly. Moreover, a good implementation of the cached etag value > might even have ramifications for the application as a whole. This is great. When I say "more sophisticated things", I meant stuff like getting the web URL for an API object, renegotiating credentials mid-application and other things that you only discover that you need after you've started to write decent-sized applications. Do you think it would be a good idea to mention some of these plans on the Launchpad blog? I reckon quite a few users would be interested. jml _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
