<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>Maxim,</p>
<p>thanks for the introduction.</p>
<p>I assume the driver would depend on the ODBC library, and would
require users to build <a class="moz-txt-link-freetext"
href="https://github.com/SAP/odbc-cpp-wrapper">https://github.com/SAP/odbc-cpp-wrapper</a>
as the corresponding ODBC driver ?</p>
<p>As GDAL is an almost always growing beast, we need to be careful
about what we accept in the upstream repository, and consider
policies about how to retire things that are no longer useful,
adequately maintained or becoming a nuisance for the overall
project. I had quite a hard time a few months ago to do some
spring cleanup (see the "Consider driver removal" thread in
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/pipermail/gdal-dev/2021-January/date.html">https://lists.osgeo.org/pipermail/gdal-dev/2021-January/date.html</a>),
and it would probably good to have a formal RFC covering the whole
life-cycle of a driver, and not just how to get new code added.<br>
</p>
<p>Below a non-exhaustive lists of points that should be covered
IMHO. A number of them are open questions where input from the
community is welcome.<br>
</p>
<p>- criteria for acceptance:</p>
<p> * (obvious) source code contributed to the repository should
follow its licensing terms</p>
<p> * is the driver of sufficient general interest ? For example,
we'd likely don't want to accept drivers for a in-house file
format of a company/organization that isn't distributed outside
it.</p>
<p> * who will review the code ? That can be really problematic.
I've just merged today the Zarr driver but nobody was available to
review it unfortunately. When we will be able to use the
sponsorship through NumFOCUS, we'll hopefully be in a better shape
to have more reviewers, but I'm not sure we'd want to spend the
sponsorship to review code for proprietary services. That should
likely be the responsibility for the proprietary service to find
an interested reviewer.</p>
<p> * should we require CI tests ? Some tests, especially ones
relying on external services, can be flaky.<br>
</p>
<p>- each (at least, new) driver should have at least one name in
front of it in the list in
<a class="moz-txt-link-freetext" href="https://github.com/OSGeo/gdal/wiki/Maintainers-per-sub-system">https://github.com/OSGeo/gdal/wiki/Maintainers-per-sub-system</a> .
What should we expect from the maintainer: monitoring of the
mailing list and issue tracker (at least bi weekly ?), some form
of handling of it (making sure the issue is well described, and
some time frame to address it when relevant), reviewing pull
requests in their "area of responsibility" (... and outside it.
For example, I see a number of QGIS developers having reviewed
your pull requests, but did you help reviewing their pull
requests. I don't mean to pinpoint on anybody in particular, as it
is a general pattern in most GDAL driver contributions too),
participation to general / cross-driver maintenance tasks, ...<br>
</p>
<p>- if someone refactors GDAL internals, who is responsible for
adjusting the various drivers to build and work properly ? Open
question honestly, and from my experience, this is a really
problematic one. I'd expect someone who wants to change some
internal API (or enable a new class of compiler warnings, or use a
new code analyzer, etc etc) to have perhaps interest and knowledge
in 3 or 5 drivers and be willing to do the changes in them, but
besides that, adjusting all the other drivers is a real burden
(remainder: GDAL has > 250 drivers) and discourage such
efforts. But even if we assumed that each driver would have a
maintainer (the reality is more like 10% of the drivers have a
maintainer), coordinating with 200 maintainers to gather patches
from each of them have a working build isn't something that is
going to work well.</p>
<p>- how can we get a sense of what is really used in GDAL ? Nobody
really knows which parts of GDAL are used nowadays, except when we
get bug reports or questions on them. Should we add some (opt-in)
telemetry (that could potentially be enabled through GUI
applications like QGIS) ?</p>
<p>- how do we decide if some code should be removed ?</p>
<p> * There are different situations according if the driver is
for a file format (files can stay forever, and GDAL is in a number
of cases the only opensource way of accessing them. But conversely
older GDAL releases are there forever too, with some effort to
build them), a database or a web-accessible service. And according
to their nature: FOSS vs proprietary.</p>
<p> * Code for which there's no longer any declared maintainer or
it has been found unresponsive (how do we declare that a
maintainer is unresponsive?) <br>
</p>
<p> * Code for which there are too many tickets unaddressed or is
known (or assumed) to be broken ?<br>
</p>
<p>- how do we actually retire code ? A PSC mention outlining the
reasons (among ones mentioned above) ? I like the experiment I did
with the runtime deprecation of a few drivers (the
GDALIsDriverDeprecatedForGDAL35StillEnabled() thing) to get some
feedback when we're unsure about the real value of a driver before
completely wiping it off (we recently get a ticket asking
re-enabling of one of the drivers that was marked fro removal in
3.5), and perhaps this could be the norm when driver removal is
considered<br>
</p>
<p>- I haven't looked at the procedures of the Linux kernel, but
perhaps there's some interesting inspiration to be taken from
there (at least for comparison)<br>
</p>
<p>Anyone wants to take the lead on such RFC ?<br>
</p>
<p>Even<br>
</p>
<div class="moz-cite-prefix">Le 19/07/2021 à 13:38, Rylov, Maxim via
gdal-dev a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:AM4PR02MB3123A11FB595552D31089E84F7E19@AM4PR02MB3123.eurprd02.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
{font-family:"Segoe UI";
panose-1:2 11 5 2 4 2 4 2 2 3;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin-top:0in;
margin-right:0in;
margin-bottom:8.0pt;
margin-left:0in;
line-height:106%;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}div.WordSection1
{page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:0in;background:white"><span
style="font-size:10.5pt;font-family:"Segoe
UI",sans-serif;color:#24292E" lang="EN-US">Dear
GDAL/OGR Project Steering Committee,<o:p></o:p></span></p>
<p
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:0in;background:white"><span
style="font-size:10.5pt;font-family:"Segoe
UI",sans-serif;color:#24292E" lang="EN-US">We, the SAP
HANA Spatial Team, would like to add HANA support to the
GDAL library.<br>
</span><span style="color:black"><a
href="https://www.sap.com/products/hana.html"
moz-do-not-send="true"><span
style="font-size:10.5pt;font-family:"Segoe
UI",sans-serif" lang="EN-US">SAP HANA</span></a></span><span
style="font-size:10.5pt;font-family:"Segoe
UI",sans-serif;color:#24292E" lang="EN-US"> is an
in-memory database with an </span><span style="color:black"><a
href="http://www.opengeospatial.org/resource/products/details/?pid=1303"
moz-do-not-send="true"><span
style="font-size:10.5pt;font-family:"Segoe
UI",sans-serif" lang="EN-US">OGC-compliant</span></a></span><span
style="font-size:10.5pt;font-family:"Segoe
UI",sans-serif;color:#24292E" lang="EN-US"> </span><span
style="color:black"><a
href="https://help.sap.com/viewer/cbbbfc20871e4559abfd45a78ad58c02/2.0.04/en-US/e1c934157bd14021a3b43b5822b2cbe9.html"
moz-do-not-send="true"><span
style="font-size:10.5pt;font-family:"Segoe
UI",sans-serif" lang="EN-US">spatial engine</span></a></span><span
style="font-size:10.5pt;font-family:"Segoe
UI",sans-serif;color:#24292E" lang="EN-US">.<br>
A free community edition of SAP HANA is available </span><span
style="color:black"><a
href="https://www.sap.com/cmp/td/sap-hana-express-edition.html"
moz-do-not-send="true"><span
style="font-size:10.5pt;font-family:"Segoe
UI",sans-serif" lang="EN-US">here</span></a></span><span
style="font-size:10.5pt;font-family:"Segoe
UI",sans-serif;color:#24292E" lang="EN-US">.<o:p></o:p></span></p>
<p
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:0in;background:white"><span
style="font-size:10.5pt;font-family:"Segoe
UI",sans-serif;color:#24292E" lang="EN-US">GDAL/OGR
supports a great variety of data formats and databases like
PostgreSQL, MySQL,<br>
MS SQL, Oracle, IBM DB2 etc. Therefore, the proposed HANA
driver would complement<br>
the list of currently supported databases.<o:p></o:p></span></p>
<p
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:0in;background:white"><span
style="font-size:10.5pt;font-family:"Segoe
UI",sans-serif;color:#24292E" lang="EN-US">The
implementation of the new vector driver for HANA including
tests and its integration<br>
into the CI would be done by our team of course with some
guidance from the GDAL community.<br>
The driver’s footprint in the code should be minimal, as the
whole implementation will reside in<br>
the subfolder </span><span style="color:black"><a
href="https://github.com/OSGeo/gdal/tree/master/gdal/ogr/ogrsf_frmts/hana"
moz-do-not-send="true"><span
style="font-size:10.5pt;font-family:"Segoe
UI",sans-serif" lang="EN-US">https://github.com/OSGeo/gdal/tree/master/gdal/ogr/ogrsf_frmts/hana</span></a></span><span
style="font-size:10.5pt;font-family:"Segoe
UI",sans-serif;color:#24292E" lang="EN-US">.
<o:p></o:p></span></p>
<p
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:0in;background:white"><span
style="font-size:10.5pt;font-family:"Segoe
UI",sans-serif;color:#24292E" lang="EN-US">Our team
already gathered some experience of working with open source
communities.<br>
A few months ago, we introduced support of HANA in </span><span
style="color:black"><a
href="https://github.com/qgis/QGIS/pull/34988"
moz-do-not-send="true"><span
style="font-size:10.5pt;font-family:"Segoe
UI",sans-serif" lang="EN-US">QGIS</span></a></span><span
class="MsoHyperlink"><span
style="font-size:10.5pt;font-family:"Segoe
UI",sans-serif">
</span></span><span
style="font-size:10.5pt;font-family:"Segoe
UI",sans-serif;color:#24292E" lang="EN-US">and now we
continue maintaining our<br>
</span><span style="color:black"><a
href="https://github.com/qgis/QGIS/pulls?q=is%3Apr+is%3Aclosed+HANA"
moz-do-not-send="true"><span
style="font-size:10.5pt;font-family:"Segoe
UI",sans-serif" lang="EN-US">contribution</span></a></span><span
style="font-size:10.5pt;font-family:"Segoe
UI",sans-serif;color:#24292E" lang="EN-US">. We keep
tracking of new issues/bugs, CI runs, API changes,
documentation improvements<br>
related to HANA and make sure that they are
fixed/implemented as soon as possible. We hope that this<br>
information will minimize your concerns about the future
maintenance of the driver.<o:p></o:p></span></p>
<p class="MsoNormal" style="box-sizing:
border-box;font-variant-ligatures: normal;font-variant-caps:
normal;orphans: 2;text-align:start;widows:
2;-webkit-text-stroke-width: 0px;text-decoration-thickness:
initial;text-decoration-style: initial;text-decoration-color:
initial;word-spacing:0px">
<span
style="font-size:10.5pt;line-height:106%;font-family:"Segoe
UI",sans-serif" lang="EN-US">Kind regards,</span><span
lang="EN-US"><br>
</span><span
style="font-size:10.5pt;line-height:106%;font-family:"Segoe
UI",sans-serif" lang="EN-US">Maxim Rylov on behalf of
the HANA Spatial Team<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>