<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">
<p>Thanks all for your reply.</p>
<p>Le 16/04/2020 à 22:39, Kristian Evers a écrit :</p>
</div>
<blockquote type="cite"
cite="mid:8D8BD109-FAB9-4109-882F-BC77748AADE9@sdfe.dk">
<p>
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
Just to clarify, Martin isn’t suggesting to put the bindings in
the main PROJ repo. The suggestion is to keep them in a separate
repo but with stronger ties to the PROJ project with the
intention of making them more visible for users. So, forking
wouldn’t be an issue and release cadence… well, that depends how
much we change the C++ API from release to release I guess.
</p>
<p>
</p>
<div class="">
<p>I agree with you both that having just one maintainer is too
fragile. </p>
</div>
<p></p>
</blockquote>
<p>Indeed. The main intent is to increase the project visibility in
the hope to resolve the "single maintainer" issue. A second intent
is to get a final programmatic namespace for the project (it
currently uses "org.kortforsyningen.proj"). The "org.osgeo.proj"
namespace would be ideal, but can be used only for projects under
OSGeo control. I'm neutral about "top level" versus "community"
versus other arrangement.</p>
<p>The maintenance needs on this project should be low. I expect
work needed only in the following situations:</p>
<ul>
<li>Evolution of PROJ C++ API.</li>
<li>Evolution of GeoAPI interfaces (very rare).</li>
<li>Evolution of Java platform (rarely an issue).</li>
<li>Build issues.</li>
<li>Needs for one of the few areas not covered by current binding
(e.g. "BOUNDCRS").</li>
</ul>
<p>Regards,<br>
</p>
<p>Martin</p>
<p><br>
</p>
</body>
</html>