<div dir="ltr"><div>Please shoot holes through my draft.  I wrote it in just a couple of minutes and I haven't really even re-read it myself.  Whatever the template contents, I think it should end up in md format so that any old text editor can edit it.  Google docs was just what was easy to mash some text into one spot.  I added a couple new things at the bottom just now.<br></div><div><br></div><div><a href="https://docs.google.com/document/d/e/2PACX-1vTtIU3WJw0APd7fXqfGVAYrBQGgURIzizb9MiXCI1trkj4PxOBZmz9o-Ne_5P7zkymM7dPjVZOCHBXl/pub">https://docs.google.com/document/d/e/2PACX-1vTtIU3WJw0APd7fXqfGVAYrBQGgURIzizb9MiXCI1trkj4PxOBZmz9o-Ne_5P7zkymM7dPjVZOCHBXl/pub</a><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 1, 2021 at 8:16 AM Howard Butler <<a href="mailto:howard@hobu.co">howard@hobu.co</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Feb 1, 2021, at 9:18 AM, Sean Gillies <<a href="mailto:sean.gillies@gmail.com" target="_blank">sean.gillies@gmail.com</a>> wrote:<br>
> <br>
> Hi all,<br>
> <br>
> Buried in a recent thread are some comments in support of requiring a GDAL RFC for new format drivers. On the surface it seems one way to keep GDAL's mass and surface area from growing without bounds. It's also been pointed out that at least one of GDAL's formats was never intended for use. Requiring RFCs might also help prevent proliferation of needlessly different web API clients and JSON formats. Or it might not, I'd love to read what others have to say about this.<br>
<br>
The thing about requiring RFCs for new drivers that is most attractive to me is the RFC will need to make the case why a proposed driver is needed. It will be a hard sell for an organization's case to be something to the effect of "it's in my business interest to do so" without assurance that the tail of updates, enhancements, and maintenance of such a thing is also provided. That assurance was implicit when someone like Even or Frank was coordinating most of the driver development while they were the primary active maintainers. As GDAL moves to a different maintenance model, that assurance can no longer be implicit.<br>
<br>
I think Even's original thread about removing a few drivers focused on kicking out "format orphans" instead of targeting "not supported by the community orphans." The former might be tougher to boot due to the community clamoring for their usage, but a common scenario is binary-only-SDK -driven format that aren't actively or adequately tested in GDAL's CI loop.<br>
<br>
> Requiring an RFC could hurt developers, though, since pay for format driver development (and other new features) is what's largely been subsidizing bug fixes and general maintenance of the project. I'm sure that others of you can think of consequences and side effects that I haven't.<br>
<br>
It is something they should build into their cost, but other projects' requirements have similar documentation needs.<br>
<br>
> I suppose we should probably have an RFC about RFCs if this idea isn't immediately shot down. Kurt Schwehr has made a template for what a driver RFC might look like and I suggest we discuss that as well.<br>
<br>
A simple motion would likely be sufficient. Requiring an RFC to add a new environment variable, on the other hand...<br>
<br>
Howard<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>