Project status

[rashadkm]

Hi,

Is this project still active here in github or in code.google.com?. I cannot find any packages for linux distribution or any release recently. The compilation itself is a mess which cant be avoided. Also the use of thridparty (boost, libz etcc.) in the source repository is again a place of 'hmmmm'. libz, boost could be an external and keeping a custom version could be removed.

libkml latest version is 1.3.0 but no official release of 1.3.0 or anything out there. Am I missing some read anywhere or this is what it is actually? Anyway just checking if google has plan to continue this as is and say "open source" or just maintaining for legacy reasons.

[sebastic]

Apparently the issues from code.google.com were not migrated to GitHub, the none existence of a proper 1.3.0 release was discussed there too:

Where is downloader for libkml version 1.3?

The state of the code and issue tracker on code.google.com speaks for itself, no changes since 2013 mean that the project is dead.

Since you and CPB9 actively contributed to your forks of libkml, I encourage you to join forces and officially take over the development of libkml. With the deprecation of code.google.com I'd like to switch the Debian package of libkml over to something that's actively maintained or remove it from the archive all together.

[rashadkm]

Thanks for reply.

Yes. the project is almost dead. this very issue adds to the list of answers. I forked it mainly to remove all third party libraries which keeps bugging me a lot with other projects. As a part of it I also did a "cmakeification" of the entire project.

I could devote my free time into development but dont know how to take over officially.

Packaging is one of the other good reasons for this fork because of bundled thirdparties make life miserable in packaging.I had suceeded in this goal upto some extent.

There is a bit of minizip remaining( it is like an extension of minizp) in the contrib - https://github.com/rashadkm/libkml/tree/master/src/kml/base/contrib

If I get some time, I will rewrite this part in a nice way without having a copy of old version of header from minizip or anything

BTW, It would be great to have this work included in offical Debian packages.

[sebastic]

Removing the 3rd party libraries is a good thing, distributions don't tend to use them anyway. I suspect they were mostly included for Windows users.

The minizip changes are very welcome, there is an outstanding issue in Debian to use the libminizip package instead of the embedded copy in libkml, but that's not possible to solve without some help from upstream developers.

To revitalize this project it would be best to have an active community contributing to its development. That's why I encourage you to also contact CPB9 who is also actively developing his fork.

https://github.com/CPB9/libkml

Ideally you and CPB9 would be added to the committers of this origin repository, but I don't know how Google thinks about that. Dubbing one of your forks the new preferred repository will work if Google doesn't want to add external contributors.

The new preferred repository needs to be communicated to the libkml users, at least GDAL and OSGEarth who link to this Google repo now that code.google.com is shutting down. The new libkml maintainers need to accept external contributors to solve the bottleneck that Google is currently.

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.

I was pleasantly surprised to see the changes from 2013 in this git repo that weren't in the subversion repo on code.google.com, but it was short lived and now looks just as dead.

[rashadkm]

Most of the bundling is for windows specific. But in case of libkml there are thirdparty for linux and windows. the system libminizip is indeed used in the fork. just the contrib has some extensions of minizip used by libkml.

For the question of windows build, the repository could host the thridparty binairies(headers && dlls) for windows somewhere and explain it detail in a wiki page.

the fork by CPB9 has additional features and more windows specific fixes. I would be more than happy if it can be merged back into upstream. instead of dubbing one of fork, I prefer to merge everything (IF google permits a new commiter or even a pull request). Not the worst case, exactly but another option is to merge both these works into a new version and use that for packaging and ofcourse in other GIS packages.

[sebastic]

I've emailed Chris DiBona, Director of Open Source at Google about the future of libkml development, and asked him or someone else involved in libkml development to comment on this issue.

[rashadkm]

Thanks! . We can wait a bit more for response from google

[redwyre]

I was talking with the libkml guys and got them to move to github to allow external development (at the time I was working on a modernised windows port), so it's just a matter of getting them to accept pull requests. But it definitely seems Google has left this project to rot (which makes me wonder what they are using internally then?).

[libkml]

exported code from googlecode, github and created this repo https://github.com/libkml/libkml. You can test, fork, create pull request there. as this is detached from orginal google code, no need to wait for anyone.

If you have windows specific commits that you would like to share, let me know.

[susi]

I realise that it might be too little to late, but it would be better for the Open Source Geo communities to have a single POC for libkml. With that in mind, we're going to pick up our responsibility of maintaining libkml again. I understand that you have already made a lot of effort in moving out to libkml/libkml, and hope that we can work towards a point where we can merge and incorporate most of your changes back to google/libkml.

In order to reach this goal we're going to need your help too, since libkml/libkml has been through quite many changes. What do you say @rashadkm, @sebastic want to work with us?

Regards, Wolf @ Google

[sebastic]

In order to reach this goal we're going to need your help too, since libkml/libkml has been through quite many changes. What do you say @rashadkm, @sebastic want to work with us?

I do.

Assuming @rashadkm is on board as well, I think he should lead the merge effort by submitting pull requests. I'm willing to help with that too.

I also think Rashad should be made Collaborator on this repo too (in a similar fashion as Frank Warmerdam was on code.google.com), as should other community members that actively contribute, to prevent this project from dying again when the Google engineers loose interest or otherwise move on.

I can imagine that it's against Google policy to accept outsiders in the google GitHub namespace, in that case it may be wiser for @susi & @schwehr to join libkml/libkml.

[mashbridge]

There's no restriction on non-Google employees being included in Github projects as committers. It makes sense to have another body there (Frank is already there). The only requirement we have is for everyone whose code is include in the repo to have signed some flavour of CLA. I've added a contributing file here to make this clearer:

https://github.com/google/libkml/blob/master/CONTRIBUTING.md

Thanks!

On 12 August 2015 at 12:04, Bas Couwenberg notifications@github.com wrote:

In order to reach this goal we're going to need your help too, since libkml/libkml has been through quite many changes. What do you say @rashadkm https://github.com/rashadkm, @sebastic https://github.com/sebastic want to work with us?

I do.

Assuming @rashadkm https://github.com/rashadkm is on board as well, I think he should lead the merge effort by submitting pull requests. I'm willing to help with that too.

I also think Rashad should be made Collaborator on this repo too (in a similar fashion as Frank Warmerdam was on code.google.com), as should other community members that actively contribute, to prevent this project from dying again when the Google engineers loose interest or otherwise move on.

I can imagine that it's against Google policy to accept outsiders in the google GitHub namespace, in that case it may be wiser for @susi https://github.com/susi & @schwehr https://github.com/schwehr to join libkml/libkml.

— Reply to this email directly or view it on GitHub https://github.com/google/libkml/issues/4#issuecomment-130262174.

[rashadkm]

It is good news that google is going to resume work on libkml and I am also on board with @sebastic . I can submit patches exported from libkml/libkml into google/libkml because I think a pull request may not be possible as libkml/libkml is exported directly from googlecode.com.

The easiest is to transfer the repository libkml/libkml to google/libkml which takes care of bugs, wiki (auto imported) along with commits. All issue from code.google.com is exported automatically with the git export tool in libkml/libkml. With transfer I think github takes care of those during the merge. Regarding write access to google/libkml all we need is sign the CLA right?. I have no problem with that, and @sebastic too I guess.

Let me know what all steps needs to be done on my side to complete the merging.

[sebastic]

Regarding the CLA, the terms seem reasonable, yes. My contributions were pretty minimal, though.

Regarding merging the code, another option is to checkout a new feature branch from google/libkml/master and merge libkml/libkml/master into it. I've done that for my libkml-merge branch. It keeps the full history, not rebased into a beautiful fake history. But there is also some merit to redoing the changes for google/libkml in more logically grouped commits.

If we can take care of moving the issues and their history from libkml/libkml to google/libkml with a transfer that's great too.

[rashadkm]

@sebastic, repo transfer moves everything including imported bugs from code.google.com. But I cannot transfer into google/libkml now. I can add @susi or someone else who has admin rights to libkml/libkml so they can do it easily. The other way is to merge into a new branch as you said.

@mashbridge, I had signed the CLA on google. It said one CLA is needed for all google project so I guess all is clear on my side.

[mashbridge]

Thanks everyone. I'm happy for @schwehr to handle the right way for the code to be smushed together. He's an admin on the repo now.

On 13 August 2015 at 07:43, Rashad notifications@github.com wrote:

@sebastic https://github.com/sebastic, repo transfer moves everything including imported bugs from code.google.com. But I cannot transfer into google/libkml now. I can add @susi https://github.com/susi or someone else who has admin rights to libkml/libkml so they can do it easily. The other way is to merge into a new branch as you said.

@mashbridge https://github.com/mashbridge, I had signed the CLA on google. It said one CLA is needed for all google project so I guess all is clear on my side.

— Reply to this email directly or view it on GitHub https://github.com/google/libkml/issues/4#issuecomment-130556278.

[rashadkm]

@mashbridge, Me and I guess @sebastic too aren't clear about if the work from libkml/libkml is going to be merged with google/libkml. Could anybody give a solid reply on this? Should I submit a pull request or transfer repo or something else?.

[sebastic]

Transferring the libkml/libkml repository is probably not going to work because both the libkml and google organisations have a repository named libkml.

This is not possible according to the Transferring between user accounts documentation:

Before you transfer a repository, keep these things in mind:

• The target account must not have a repository with the same name, or a fork in the same network.

The google/libkml repository doesn't have the issues from code.google.com imported, transferring the libkml/libkml repository would have moved the issues over too, but that's apparently not an option. The issues should be imported from code.google.com into google/libkml along with the wiki some other way, I'm not sure if the Export to GitHub tool supports exporting only the issues and wiki into an existing GitHub repository.

@rashadkm already did some bug triaging in libkml/libkml that will need to be redone for google/libkml after the issues are imported.

Because transferring the repository isn't an option, that leaves Pull Requests to get the changes from libkml/libkml into google/libkml. We may need to have the individual contributors (me & @AlexBobkov) to sign the CLA first before their commits can be merged. The simplest option is one big PR with all changes from libkml/libkml merged into google/libkml as I did in my libkml-merge branch, or a couple of PRs with the changes redone for google/libkml skipping the intermediate commits.

[rashadkm]

yes transfer needs the current repo renamed or moved which can be done from google side. But I dont think they are going to do that. A single PR from my side is here https://github.com/google/libkml/pull/6. I asked/waited to have a clear word from google regarding merging or transferring. In this case it was none as before and I assume a PR might work.

[susi]

@rashadkm @sebastic I get that you're ancious to hear back from us, but please be a bit patient, while we ponder things though internally. :) I think that one or a few PRs might indeed be the best way to go, but will wait for @schwehr to give the final word here as the new project lead.

That huge PR is a lot of code to go through in one go. That said, I'll try to start looking at it over next week. It still needs to be gone through, so might as well start :)

I'll post comments on the PR of any findings I might have.

[rashadkm]

Thanks @susi. I agree that PR is huge and it will take a lot of time to review. That was the reason I asked about a preferred way that could be easy for you. multiple PR's will be a bit more easy for you to review but that takes time on my side. On the other hand, transferring is super easy but there is one issue mentioned by @sebastic. That can be however fixed in your side.

And in this case, the question is not about being patient and waiting around because as you know we had done that before also. :).

[schwehr]

To keep from being silent for too long... I am currently going through the gdal KML and LIBKML driver tests to make sure I understand where things are at and to do some minor cleanup. My changes show up in gdal svn as the user "goatbar". e.g. https://trac.osgeo.org/gdal/changeset/29658

[schwehr]

I now have a dump of the issues from code.google.com and will attempt to load them here soon. I've been working hard on GDAL for a couple months now and will try to get more done on libkml soon.

[sebastic]

Great news! Can you also share your thoughts about the single shared library question in https://github.com/libkml/libkml/issues/215?

[schwehr]

Sorry for no progress. I'm still here, but have been working hard on GDAL. See more in https://github.com/libkml/libkml/issues/215#issuecomment-244629185

e.g. http://erouault.blogspot.com/2016/01/software-quality-improvements-in-gdal.html

[adamjstewart]

What's the status of this merge? I'm looking to add a libkml package to the Spack package manager. I would love to know what the "official" source is these days.

[schwehr]

Please consider https://github.com/libkml/libkml the official source.

[thclark]

Can one of the google folks (@susi or @schwehr ) please add the previous statement (or sth to that effect) prominently to the README of this library please?

I'm honestly somewhat irritated, having taken hours to go through the painful build process here, only to discover this codebase isn't maintained in favour of one somewhere else (which comes up much lower on search engines).

Thanks.