Re: Making the next gnome-applets depend on libgweather.

On Sun, 2008-01-13 at 21:13 +1300, Callum McKenzie wrote:
> I have a version of the gnome-applets code base that uses an external
> version of libgweather. I would like use this for the 2.21.5 release, so
> I'm asking if anyone has serious objections.
> Obviously this relies on Federico getting a tarball release of
> libgweather out the door (I'll be making my decisions at approximately
> 9am UTC on the 14th of January, if a release isn't done by then I will
> wait - possibly until 2.23 since we're getting on in the cycle).
> The effects this should have:
> i18n: No new strings, but some files with strings and the massive
> Locations.xml are moving. I think everything has been migrated properly,
> so translators should merely have to point their tools at a new place.
> Documentation: None, there is no UI (although the gweather applet
> location selection UI may eventually be migrated) and the API isn't
> actually documented.
> Bugzilla: Bugs about locations and the like will almost certainly end up
> getting filed against the gweather applet rather than libgweather. This
> is probably something we'll just have to live with - its the same with
> all libraries.
> In principle this shouldn't be a major change since it is effectively
> splitting an existing code-base in two rather than introducing a new
> dependency. However, I don't want to do anything without asking first.
> Current SVN trunk has the relevant code - although I'm prepared to
> revert (I managed to create a branch with the code and then commit the
> same code to trunk).
> Comments, criticisms?

I'm slightly concerned by this ... libgweather does something pretty
interesting (to a small set of consumers) but the API is no way ready
for any sort of freezing. It has serious namespace and memory management
issues, among other things.

I don't think there is any proposal here to make libgweather part of the
platform, but a) is there clear messaging about the API status? b) how
would a transition to an incompatible new version be handled?

- Owen

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]