<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 28, 2023 at 10:10 AM Ricardo Filipe Soares Garcia da via pygeoapi <<a href="mailto:pygeoapi@lists.osgeo.org">pygeoapi@lists.osgeo.org</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"><div dir="ltr"><div>Thanks for preparing the RFC, I think pygeoapi needs more of this type of stuff :) </div><div>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.</div><div><br></div><div>More specifically:<br></div><div><br></div><div>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:</div><div><div><br></div><div>"...<br></div><div>master branch dependencies and requirements shall be consistent against a given operating system baseline:</div><div><br></div><div>- Ubuntu dependencies<br>- pip3 requirements<br>- Docker / Docker Compose<br></div><div>..."</div><div><br></div><div>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. <br></div></div><div><br></div></div></blockquote><div><br></div><div>Yes. pip3 requirements (at the time of release at least) shall be available on Ubuntu. Docker and Docker Compose would be built off Ubuntu as well.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div>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:<br></div><div><br></div><div>- What would be some criteria for deciding whether an additional dependency ought to be added? </div></div></blockquote><div><br></div><div>Based on personal experience, the idea would be (on top of Ubuntu availability):</div><div><br></div><div>- health/pulse of a dependency as a project<br></div><div>- is the dependency really needed? For example, can the same functionality be achieved with Python primitives or the standard library, even if less elegant?<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- 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 <br></div><div><br></div></div></blockquote><div><br></div><div>This may become a moot point as we evolve to 1.0. The thinking is that pygeoapi proper would be a minimal set of plugins with bare / minimal dependencies, and that a pygeoapi-plugins repository would be a growing repository where pygeoapi plugins would be maintained / developed. To be discussed at our upcoming meetings/sprints.<br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div>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:<br></div><div><br></div></div></blockquote><div><br></div><div>Yes, I think this approach is needed for the long term viability of pygeoapi. It is work, but it is also sustainable and a sign/indicator of a serious project with a long term commitment.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>- 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)?</div></div></blockquote><div><br></div><div>We would have a stable branch for every major and minor release. We would also need a policy of how may branches are supported. n - 1, for example, would be a suitable approach. There will always be exceptions of course (think a CVE which would need patching and backporting across numerous previous versions).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- 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.</div><div><br></div></div></blockquote><div><br></div><div>I think our critical path support is Ubuntu, but yes that doesn't stop us from providing additional channels (see <a href="https://docs.pygeoapi.io/en/latest/installation.html">https://docs.pygeoapi.io/en/latest/installation.html</a> for example).<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>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?</div><div><br></div></div></blockquote><div><br></div><div>+1 to discuss in another thread/meeting/sprint.</div><div><br></div><div>Note that RFC2 has now been updated and now going for PSC vote.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Anyway, thanks for putting it forth and I hope these help in improving the overall document.</div><div><br></div></div></blockquote><div><br></div><div><br></div><div>Thank you for your valuable feedback Ricardo!</div><div><br></div><div>..Tom<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Best regards<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Tom Kralidis via pygeoapi <<a href="mailto:pygeoapi@lists.osgeo.org" target="_blank">pygeoapi@lists.osgeo.org</a>> escreveu no dia terça, 28/11/2023 à(s) 00:09:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi all: as discussed at the OSGeo Community Sprint earlier this month, please find RFC2 [1], for</div><div>review and discussion. If/once we update as needed, I will put to a PSC vote for formal approval.<br></div><div><br></div><div>Thanks</div><div><br></div><div>..Tom<br></div><div><br></div><div>[1] <a href="https://pygeoapi.io/development/rfc/2" target="_blank">https://pygeoapi.io/development/rfc/2</a></div></div>
_______________________________________________<br>
pygeoapi mailing list<br>
<a href="mailto:pygeoapi@lists.osgeo.org" target="_blank">pygeoapi@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/pygeoapi" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/pygeoapi</a><br>
</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">___________________________ ___ __<br>Ricardo Garcia Silva</div>
_______________________________________________<br>
pygeoapi mailing list<br>
<a href="mailto:pygeoapi@lists.osgeo.org" target="_blank">pygeoapi@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/pygeoapi" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/pygeoapi</a><br>
</blockquote></div></div>