[pygeoapi] for review: RFC2: Dependency policy

[Ricardo Filipe Soares Garcia da]

Thanks for preparing the RFC, I think pygeoapi needs more of this type of
stuff :)
I wish it would be a bit more detailed though. Perhaps I'm just missing the
context from the discussions that were already had about it, but having
just read it, I found the text to be very succinct, and was left wanting to
know more details about the proposal.

More specifically:

1. With regard to the actual dependency management policy, I must admit I
did not really understand some parts of it - perhaps it could be a bit more
verbose, even with one or two examples thrown in there? To elaborate on
this, when the text mentions that:

"...
master branch dependencies and requirements shall be consistent against a
given operating system baseline:

- Ubuntu dependencies
- pip3 requirements
- Docker / Docker Compose
..."

Excuse my obtuseness, but what does this mean exactly? Is it that the
master branch shall only rely upon those libraries (and respective
versions) which can be found on a given OS' baseline repositories, which I
guess is being proposed to be the current Ubuntu LTS? And then the various
requirements.txt files and Dockerfile would restrict themselves to the same
libraries and versions? - I'm not saying I do not agree with such a policy,
it is just that I did not really understand if it is this or something
else.


2. The RFC mentions that "...Careful consideration shall be given when new
dependencies are proposed..." but I would like it to elaborate on this with
points about:

- What would be some criteria for deciding whether an additional dependency
ought to be added?
- What would be the process to follow for when a new dependency is being
considered or proposed? I think this could be documented somewhere. I see
this question as being relevant in the context of pygeoapi providers and
their inclusion as part of the 'core pygeoapi experience' and what would be
a good policy for inclusion, as it seems most dependencies would come from
providers. But there are other cases where it could be beneficial to have
some guidelines - with recent examples being the usage of gunicorn or
pydantic. Just to be clear, I'm not trying to make the case for inclusion
of any dependency - this is just so that the whole process becomes a bit
clearer and easier to adhere to


3. The RFC mentions that pygeoapi maintainers would provide a master branch
and additional maintenance branches for each minor and major release, with
relevant security fixes being backported from master. This seems like a
substantial increase in maintenance-related work, but I guess it may depend
on additional details, which the RFC does not provide. Some questions I
think would be worth considering:

- How many simultaneous stable branches do you propose to have in addition
to master? Does it make sense to keep more than one (which would be the
latest release)?
- The RFC mentions a number of dissemination channels (UbuntuGIS, pip3,
docker, etc) as being officially supported. Do you want to keep all of
them? Could there be other dissemination channels that make sense
considering? I imagine that each of these distribution channels would also
need to be updated whenever a new maintenance version got pushed.

I'm wondering if this last item would not be perhaps more appropriate for a
post-1.0.0 release? Or maybe be the subject of a different RFC?

Anyway, thanks for putting it forth and I hope these help in improving the
overall document.

Best regards


Tom Kralidis via pygeoapi <pygeoapi at lists.osgeo.org> escreveu no dia terça,
28/11/2023 à(s) 00:09:

> Hi all: as discussed at the OSGeo Community Sprint earlier this month,
> please find RFC2 [1], for
> review and discussion.  If/once we update as needed, I will put to a PSC
> vote for formal approval.
>
> Thanks
>
> ..Tom
>
> [1] https://pygeoapi.io/development/rfc/2
> _______________________________________________
> pygeoapi mailing list
> pygeoapi at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/pygeoapi
>


-- 
___________________________ ___ __
Ricardo Garcia Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pygeoapi/attachments/20231128/0dc88627/attachment.htm>