Reporting in from the PSC Meeting, can I ask for a vote on the following proposal:
Thanks everyone
Reporting in from the PSC Meeting, can I ask for a vote on the following proposal:
Thanks everyone
+1
+1
Jeroen
---- Op do, 26 sep. 2024 16:54:00 +0200 schreef Jody Garnett via OSGeo Discourse noreply@discourse.osgeo.org ----
jive Leader
September 26Reporting in from the PSC Meeting, can I ask for a vote on the following proposal:
Thanks everyone
Visit Topic or reply to this email to respond.
To unsubscribe from these emails, click here.
Thanks to those that have voted on the proposal thus far.
While it has been two business days, I would actually like to get a response from the core PSC members for such an important change (@etj, @josegar74, …).
Ideally we schedule the transfer of the codebase to the github.com/geonetwork this week.
PSC support:
- Emanuele Tajariol:
- Florent Gravin: +1
- Francois Prunayre: +1
- Jeroen Ticheler: +1
- Jose Garcia:
- Paul van Genuchten:
- Simon Pigot:
Community support:
- Jody Garnett - +1 initial motion
There were lots of good architecture questions during the sprint last week - and the answers are not yet known. This is very much a statement of intent - a bold plan to tackle the spring-framework-6 and saxon update.
+1
Welcome to discourse Simon, glad you could make it
+1 from me, thanks for starting this initiative! Although I think it is important to clarify how will the frontend of GeoNetwork 5 be handled, because it has never been clearly discussed so far and the UI of GeoNetwork is one of its most critical elements.
Hi @jahow and others,
Thinking about how we handle the front end is indeed important! My thoughts very much go to having something like an App approach where you decide what Apps you would like to use in your solution. From such a perspective, the front end would be more use-case focused. So if you want to see a Datahub search front end, a harvesting App, a contributor App, a Super Admin App, a Contract management App (who has access to what and under what conditions), et cetera.
Such a structure would make it easier for contributors to develop their own specialised App that fits their use case. There could be core Apps as well as community Apps.
A similar approach could be taken for Extensions that add new functionality within existing Apps.
If you have ideas on how to implement and facilitate such a process (e.g. how does someone extend e.g. the DataHub) I’m keen to hear about that.
Cheers,
Jeroen
I always valued the api division between client and server (geonetwork benifited from this once already going from geonetwork 2 to 3). The ideal is to have 3 clients in the mix when setting up a rest api - to avoid making anything app specific.
So if you have integration tests you could setup for geonetwork-ui it would be helpful to stabilize during the transition. We should also cull any api that is not being used.
But we should be clear - the priority is to get to spring-framework-6 and avoid being in a vulnerable unsupported environment. While support for older versions of spring framework is available commercially - it can be quite expensive.
As this approach ports a module over at a time it scales up of any additional teams get funding to participate. I think this is an amazing response and would love to see it move forward promptly.
Hi @ticheler, thanks for the feedback. I 100% agree on the apps-based approach, and having a more straightforward Search API will definitely help in that regard.
One request that I’ve heard many times is that GeoNetwork should still come with a “default” frontend that just works. so I guess there should be at least some frontend bundled with the GeoNetwork web app, e.g. administration and basic search.
@josegar74 you have not replied to this proposal, as a PSC member I am going to mark you down as 0
unless you wish to speak up now?
@etj you have not replied to this proposal, as a PSC member I am going to mark you down as 0
unless you wish to speak up now.
update: Sorry I see on the wiki that you are listed as a former PSC member.
Motion is passed.
PSC support:
Community support:
Core contributors: