[gdal-dev] Requiring RFCs for new format drivers

[Kurt Schwehr]

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.

https://docs.google.com/document/d/e/2PACX-1vTtIU3WJw0APd7fXqfGVAYrBQGgURIzizb9MiXCI1trkj4PxOBZmz9o-Ne_5P7zkymM7dPjVZOCHBXl/pub

On Mon, Feb 1, 2021 at 8:16 AM Howard Butler <howard at hobu.co> wrote:

>
>
> > On Feb 1, 2021, at 9:18 AM, Sean Gillies <sean.gillies at gmail.com> wrote:
> >
> > Hi all,
> >
> > 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.
>
> 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.
>
> 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.
>
> > 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.
>
> It is something they should build into their cost, but other projects'
> requirements have similar documentation needs.
>
> > 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.
>
> A simple motion would likely be sufficient. Requiring an RFC to add a new
> environment variable, on the other hand...
>
> Howard
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210201/5735ff53/attachment-0001.html>