Reminder that the next PMC meeting is scheduled for tomorrow, April 8, at 18:30 CET.
We’re back in sync with DST between Europe and NA, so this’ll be 9:30 AM PDT again.
I will not be able to attend the meeting this week.
This ended up being a significant release! Thanks to everyone involved.
CITE certification was not ready quite yet, see below
actions:
gabe: some small update for dev guide, updating conf.py by hand no longer needed
How to make it less work to do a release? And still maintain option to build older archive branches…
Quick: Create main/stable/maintenance/archive jobs and just switch branches rather than creating new jobs. This implies we duplicate the last archive (2.25.x) job to create a new (2.26.x) job
Alternative: Make a Jenkins file and check it into the source code for each branch.
This would take a bit more work, the result is more similar to github workflows.
Simplify GWC release process
The xsdoc step has fallen out of use; perhaps this could be removed?
the XSD docs on sourceforge have zero downloads
The XSD also produces errors on GeoServer startup
Replace the ruby script with bash, or update from Ruby 8.7… (AI translation to Bash anyone?)
Jody has some ant scripts that could be adapted
Limit CITE certification to major release? Maybe only one a year to avoid undue costs
Trust github actions to “pass” for the dot releases
We may occasionally need a GeoServer 2.27.0.1 to pass if OGC is using older/newer CITE Team Engine
CITE Certification
Peter and OSGeo is working it.
OSGeo MOU says that that they can only so many “reference implementations”
OAuth2 is another example that can be worked on independently
These things can stay as 2.28-SNAPSHOT for September 2.28.0
Milestone 2:
This is the point where 2.28.x ends and 3.0.x starts…
Do we take over main? After making 2.28.0 above? Or make a “devel” branch (which is nice for website home page which already provides such a thing for RCs)
Milestone 3
everyone back in the pool
If you had a community module you love; now is the time to test + retain it
Q: Expected timeframe
Milestone 1, Starts in May …
Milestone 2, starts when ready trying for 1-2 months crunch
Q: What to tell people about contributing
Codebase is open for Milestone 1
Locked down for Milestone 2, so important to keep this small
Workspace cloning and synchronization
To be disregarded as the customer’s withdrawn the request for support
Tracking admin user making config changes
Existing UI options show creation / modification time that is already recorded
Proposal is also to record new information, the admin that made the change.
privacy aspect? track only when display is required …
right to be forgotten in europe; make a bulk change tool …
or reacts to removal of a user…
we do not get notified when user is removed in LDAP, so tool is perhaps preferable