Bolsena 2018

Agenda for the Bolsena Code Sprint 2018

Link to the event: https://wiki.osgeo.org/index.php?title=Bolsena_Code_Sprint_2018

Presentations & discussions

• schema creator script (https://github.com/josegar74/generator-geonetwork-metadata-schema)
• GeoNetwork community update (icebreaker) minutes
• Releases & roadmap
  • What will be the next one 3.4.3/3.6.x/4.0.x
  • Improve management of releases: Actually when done a release, the release branch gets not only bug fixes, but additional features. This is quite problematic as are introduced new bugs and regressions. A proposal, is to define a release calendar 1/2 releases per year and stick to them. When a release is done, lets say 3.6 that branch should only get bug fixes. Any improvement or new feature must be added in the develop branch, that will be in the example the base for 3.8 release. If we stick to 1/2 releases per year that should be quite feasible, improving the quality.
  • Create schema packages in the nightly builds. Currently schemas in https://github.com/metadata101 require to be build by users, not always an option. Check to use nightly builds server to build also schema packages so can be added to GeoNetwork easily.
  • Move releases to GitHub instead of Sourceforge.
  • E2E testing (cucumber?) and identification of html elements
• Advances in and roadmap for search engine friendlyness
• Inventarisation of WCAG accessibility options/requests
• Configuration outside war (config file, jndi, data folder, environment)
• DCAT schema-plugin inventarisation of interest

Work items

• Review/merge of pull requests (https://github.com/geonetwork/core-geonetwork/pulls)

• Integrate metadata draft feature

• Change schema plugin artifact identifiers: Currently metadata schemas use the same versioning for the artifact identifiers as the other modules. You need to keep them aligned with the related latest branch in GeoNetwork: 3.4.1-SNAPSHOT, 3.4.2-SNAPSHOT, etc. To use the the release number for schemas module, so for GeoNetwork 3.4.x branch we use for shemas the artifactId 3.4. In the future, when released GeoNetwork 3.6, the schemas in 3.6.x branch will use artifactId 3.6 and so on. This is only for schemas module, the rest of the modules will be managed as actually.

• Upgrade of libraries to latest minor version releases to get security fixes.

• Improve website build to publish only the english manual or if possible to check with transifex API, the manuals for languages translated at least 70%

• GeoNetwork 4 ?

  • How/When to move to ES? A team of 4 or 5 people could do a good start in a week! (Francois, ...?)

    • https://github.com/geonetwork/core-geonetwork/pull/2830
    • is it an option to keep lucene for basic deployments?
    • would it be very impactfull to allow users to select their favourite index (solr, es, lucene, couchdb, postgresql)
    • Discussions:
      • Create abstraction layer which could help moving/supporting other search index
      • Use ES API for search and response
      • Create a q service backward compatible service
      • Make decision about which search services should be kept: CSW, SRU, opensearch, q
      • Overview of ES SQL Plugin
      • Some possible documentation on ES and Kibana for Geonetwork admins

  • Remove old Jeeves services

  • Process priority, background tasks

  • External settings

  • Formatters, who is still using groovy?

  • still based on ngeo/jsonix/openlayers/angular/wro4j or are there alternatives