Discussion: GSIP 233 - Unsupported Extensions

GeoServer GeoServer Developer
1

Proposing recognizing the “release” profile community modules as “unsupported extensions” as part of the release process.

For discussion: GSIP 233 · geoserver/geoserver Wiki · GitHub

Jody

2

Sounds fair to me - +1

Ian

3

+1

4

Hard -1 for the proposal as it is written now, we cannot have releases with random stuff that is barely working, and move it to be part of the release at the request of a random party, even if it’s labelled as “community”.

Let me propose some alternatives to make it more reasonable. What I think we can have is an “extension light” mode, with the clear intent to gather funds/coders and eventually move the module to extensions:

  • The module should still be of general interest
  • The proposal can be done only by someone that acts as the maintainer of the module. Rationale, if we give the module more visibility, we need someone responsible for basic care and feeding, answering questions and reviewing PRs against the module. A module without a maintainer backing its basic needs won’t have a chance to graduate anyways (until one maintainer shows up).
  • The maintainer has signed the CLA and has no IP violation, we don’t release code that we don’t own and will have no chance of graduating later.
  • Passing the test should not be optional, if the module does not pass them, it gets kicked out of the release. However, we can have a lower percentage than for extension. I would suggest we raise the bar for extension to 60% (it’s now 40%) and have 30% for the unsupported extension
  • Just like for community modules, there is no requirement to pass QA
  • The page in the documentation should be clearly explaining why the module is not in extension “proper”, but as a community release. E.g. if it was COG;
    • The module cannot handle large COGs without setting a system variable (which in turn will make smaller COGs less eficient)
    • The modules does not have online tests covering the various clouds, we have no idea if a given cloud is working or not
    • On top of that, a generic message suggesting people to provide fund/coding to cross the above chasm
  • Just like with community modules, core developers should not be bothered by maintenance of the module: if the module stops passing tests due to core changes, the developer performing such changes can kick out the module without asking any questions.

In other words, same as extension, but with lower testing requirements, a clear message about what’s missing, no indication that the module is considered stable from the majority of the PSC, and no requirement for core devs to keep the module in the build, unless they actually care about it and want to spend time baby sitting it.

Regards,

Andrea Aime

5

Thanks Andrea!

I was opening this proposal for discussion, not votiing. Your feedback is what I am seeking (for anyone who voted +1 above please let me know what you like about the proposal).

I like and agree with your feedback, makes me wonder what is in the release profile that does not meet the requirements you outline :slight_smile:

I really like your idea of asking that the module document what is needed to make it an extension. I feel this important messaging that is missing presently.

Q: Will this proposal, revised with your feedback above, take some of the pressure off the request to allow community modules to be used with docker releases?

I would like to make the current situation more simple:

  • community: under development (or phasing out of development)
  • unsupported: extension lite is a good definition

Phrased another way is there some “mission critical” community modules that do not have sufficient backing to make the cut?

if the module stops passing tests due to core changes, the developer performing such changes can kick out the module without asking any questions

I would like to automate that if we can…

Q: I wonder if we could set the maven unsupported/pom.xml up so that test failure is consider a warning for these modules and does not break the build? Research: <maven.test.failure.ignore>true</maven.test.failure.ignore> may do the trick.

6

I don’t understand this comment… the mail basically took the requirements to graduate a module to extension, and watered them down to a “extension lite” status. Please clarify.

Mind, this is an ask from people that just want to use the community modules without putting any extra effort in it, no money, no development time, and not even folllowing instructions on how to add additional extensions… they just need to locally download the nightly build module, unpack in a folder, and add a parameter in the command line. Then the deploy is repeatable. I don’t think it’s worth our time to help out users with this attitude.
It’s however worth it to help active community members to find collaborators or funding, in order to push a community module up to full extension.

Do we actually need to come up with new naming replacing the one we used for the last 10+ years? Community modules should be enough, some are in the release, others are not. “Selected community modules are included in the release to help users try them out, and if they find them useful, decide to sponsor their development up to full extension”. Stick that message in the release page template and call it done?

A functionality that’s “mission critical” and at the same time gets no funding whatsoever seems like a contradiction. But one could say, users might decide to use a different product that provides this functionality out of the box instead.
Again, what I want is to incentive test and then hopefully funding, the ones that complain but do nothing are just giving a net negative contribution to the community as a whole.

How do we know the module build is broken and take action to remove them form the release, if we don’t see a broken build?
I’d make it the responsibility of the developer breaking such build to decide if they want to fix it, or to kick the module out of the build.

Cheers
Andrea