GSIP 129
Jody Garnett
The live developers guide is based off master, so the sooner we can correct the better :)
- Under Discussion
- In Progress
- Completed
- Rejected
- Deferred
In reviewing the developers guide a few sections are out of date:
- we have changed from roadmap planning to a time boxed release cycle
- cross link to to Release Cycle
- Update to quickstart to modern branches
- Correct GEOSERVER_DATA_DIR VM argument example
- We can use a section on "responsible disclosure" of security issues
- Push the code freeze back a month, and remove the RC2 release. This provides a bit more coding time each cycle and is a response to the lack of feedback on release candidates
- The result is a development cycle on master than ends with: beta, RC1 (code freeze), release
- Clarify that fixes are expected to be back ported to the stable and maintenance branches (or what is the point of having them)
- This will be a strong recommendation for now (rather than a requirement).
The following should be able to proceed without formal approval (as it reflects our project changing over time, rather than a change in policy):
- change to build procedure
- developers guide tutorial review and cleanup
- We can also take the opportunity to refresh our PSC list based on activity
Changing the following procedures are subject to review and approval by the PSC:
-
Removing the section on roadmap planning
-
Adding a section on responsible disclosure
- keep exploit details out of issue report
- send to developer/PSC privately (just like we do for sample data)
- be prepared to work with PSC members on a solution
- if you are unable to communicate in public/issue tracker please contact PSC members privately, or contact OSGeo at info@osgeogeo.org
- keep in mind PSC members are volunteers and an extensive fix may require fundraising / resources
-
Adjusting the release schedule for July beta, August RC1 (and code freeze), September release
-
Clarification on our expectations for submitting fixes to
Patch/jira/pull request workflow is expected to be as follow:
- Master should the first branch where the fix shall land
- An investigation on whether or not the issue impact all the active branches (master / stable / maintenance) shall be performed
- An investigation on whether or not the fix can be backported to all the active branches (master / stable / maintenance) shall be performed
- Point 2 and 3 shall be captured in jira or in the PR comment
- Actual backport to stable and maintenance is optional but highly recommended
Backporting to stable/maintenance will remain a strongly recommended activity rather than a requirement. Performing the investigations at point 2 and 3 as well as reporting them (Point 4) are mandatory.
It is worth to point out that feature backports from master to the other branches should still follow the 1 month rule. Backporting a bugfix is by default doable without asking on the developer mailing list, although it's left to the common sense of the developer to initiate a discussion if the fix is large or touching a critical area. It is of course recommended that a full build is made every time a backport is performed.
Discussion on reasonable disclosure:
- Handling of GEOS-7032: Remote File Disclosure - concerning XML External Entity XXE Processing and GEOS-7032
- Handling of a security flaw - concerning cross site scripting flaw
Discussion on developer guide procedures:
Change to developers guide are not "backwards compatible", we may wish to make the "latest" developers guide more visible on docs.geoserver.org (to prevent community members consulting out of date information).
Project Steering Committee:
- Alessio Fabiani
- Andrea Aime +1
- Ben Caradoc-Davies +1
- Christian Mueller +1
- Jody Garnett +1
- Jukka Rahkonen +1
- Phil Scadden +0
- Simone Giannecchini +1
Committers:
- GEOS-7054
- https://github.com/geoserver/geoserver.github.io/pull/20 - revised website communication page
©2022 Open Source Geospatial Foundation