launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Thu, Dec 17, 2009 at 11:59 PM, Gary Poster <gary.poster@xxxxxxxxxxxxx> wrote:
>
> 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)
>

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