launchpad-dev team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

On Dec 16, 2009, at 8:01 PM, Jonathan Lange wrote:

> On Thu, Dec 17, 2009 at 1:52 AM, Francis J. Lacoste
> <francis.lacoste@xxxxxxxxxxxxx> wrote:
>> On December 15, 2009, Jonathan Lange wrote:
>>> On Wed, Dec 9, 2009 at 6:28 PM, Jonathan Lange <jml@xxxxxxxxxxxxx> 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)

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.

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.

> 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.
- 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.

Gary