[gdal-dev] Regarding libkml driver

[Wolf Bergenheim]

On 12 August 2015 at 13:04, Sebastiaan Couwenberg <sebastic at xs4all.nl>
wrote:
>
>
> I've also commented on the Project status GitHub issue:
> https://github.com/google/libkml/issues/4
>
> As I wrote in an earlier comment:
>
> "
>  I'd love to see all GIS developers rally around the new preferred
>  repository to collaboratively maintain libkml, breathing new life into
>  this useful library because there are no good alternatives.
> "
>
> The community involvement in libkml development is essential in my
> opinion to prevent the project from dying again when the Google
> engineers loose interest or otherwise move on.
>
> What are your thoughts about that?
>
>
I fully agree with mashbridge, that we should welcome non-google Committers
to the project.


> Maybe it would make sense to form libkml into an OSGeo project?
>

That's probably not going to happen, as that would mean giving away libkml,
which we don't want to do, at this point in time at least. It is, and will
continue to be a Google owned project.

>> Most importantly the final 1.3.0 libkml release is long overdue, it has
> >> been required for GDAL for many years now but many distributions still
> >> ship libkml 1.2 (Fedora removed libkml even because it was abandoned
> >> upstream). What do you think needs to be done to get the 1.3.0 release
> out?
> >
> > Hmm. I think that we should first get to the point where we can merge the
> > libkml/libkml stuff back to google/libkml before we push out a new
> release,
> > in order to avoid confusion and mess.
>
> We definitely need to sort out how to continue libkml development, what
> to do with the forks (Kitware has many changes in their fork too that
> should be considered).
>
>
Agreed. It's good to see that we seem to be in agreement on how to
continue. I'd say that the next steps would be to start getting those


> > Also we might want to call it libkml 2.0.0 so we don't really need to
> worry
> > about backwards compatibility.
>
> The libkml 1.3.0-rc0 release from libkml/libkml already includes a
> SONAME bump to account for the minizip changes.
>
> Bumping the version to 2.0.0 makes sense if more drastic changes are
> included, otherwise it seems better to follow the 1.2 release with 1.3.0.
>
>
Yea, I suppose that  would work. Just thinking less technically on this. :)
I don't have any strong opinions on the version number.

I'm beginning to wonder if we should have our own libkml mailinglist, since
all this talk is strictly not GDAL... But as long as no-one objects. But
that's also something to think about for the future.

--Wolf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150812/be2eb070/attachment.html>