<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 12 August 2015 at 13:04, Sebastiaan Couwenberg <span dir="ltr"><<a href="mailto:sebastic@xs4all.nl" target="_blank">sebastic@xs4all.nl</a>></span> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
</span>I've also commented on the Project status GitHub issue:<br>
<a href="https://github.com/google/libkml/issues/4" rel="noreferrer" target="_blank">https://github.com/google/libkml/issues/4</a><br>
<br>
As I wrote in an earlier comment:<br>
<br>
"<br>
 I'd love to see all GIS developers rally around the new preferred<br>
 repository to collaboratively maintain libkml, breathing new life into<br>
 this useful library because there are no good alternatives.<br>
"<br>
<br>
The community involvement in libkml development is essential in my<br>
opinion to prevent the project from dying again when the Google<br>
engineers loose interest or otherwise move on.<br>
<br>
What are your thoughts about that?<br>
<br></blockquote><div><br></div><div>I fully agree with mashbridge, that we should welcome non-google Committers to the project.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Maybe it would make sense to form libkml into an OSGeo project?<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>> Most importantly the final 1.3.0 libkml release is long overdue, it has<br>
>> been required for GDAL for many years now but many distributions still<br>
>> ship libkml 1.2 (Fedora removed libkml even because it was abandoned<br>
>> upstream). What do you think needs to be done to get the 1.3.0 release out?<br>
><br>
> Hmm. I think that we should first get to the point where we can merge the<br>
> libkml/libkml stuff back to google/libkml before we push out a new release,<br>
> in order to avoid confusion and mess.<br>
<br>
</span>We definitely need to sort out how to continue libkml development, what<br>
to do with the forks (Kitware has many changes in their fork too that<br>
should be considered).<br>
<span class=""><br></span></blockquote><div><br></div><div>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 </div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Also we might want to call it libkml 2.0.0 so we don't really need to worry<br>
> about backwards compatibility.<br>
<br>
</span>The libkml 1.3.0-rc0 release from libkml/libkml already includes a<br>
SONAME bump to account for the minizip changes.<br>
<br>
Bumping the version to 2.0.0 makes sense if more drastic changes are<br>
included, otherwise it seems better to follow the 1.2 release with 1.3.0.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Yea, I suppose that  would work. Just thinking less technically on this. :) I don't have any strong opinions on the version number.</div><div><br></div><div><div>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.</div></div><div><br></div><div>--Wolf</div></div></div></div>