A proposal for long and short term roadmap process and its relationship with releases and testing. Builds son top of the [GSIP 30 - Roadmap Process|GSIP 30] experience and tries to improve over it.

Andrea Aime Jody Garnett

Should be driving the GeoServer development during the 2.0.x series

Choose one of: Under Discussion, In Progress, Completed, Rejected, Deferred

Never completed, and much of what it tried to accomplished has been iteratively improved.

As already stated in [GSIP 30 - Roadmap Process](GSIP 30) we want a roadmap and release process that increases transparency and predictability, enabling all developers to participate in the planning and evolution of GeoServer, as well as allowing users to get an idea of where GeoServer is headed.

Compared to GSIP 30 this iteration suggest a different presentation of the roadmap and works a bit more on the details and responsibilities of the involved parties.

The road map is a time line of planned releases and features:

• The short term roadmap concerns with releases, their dates, and the day to day evolution of the project.
• The medium term roadmap concerns major features that cannot be introduced in the current release, but that do have resources backing it, and will be thus included in the next release.
• The long term roadmap concerns major features that will be developed in the next stable series of GeoServer, as well as major features that are desired, but are lacking resourcing to be implemented.

The roadmap is a document that anyone can read to get the pulse of the current and future GeoServer development. As such it’s written in plain english and refers to Jira to provide a terse summary of the issues, both closed (work already done) and still open (work still scheduled for the next release).

Each release has a single page in the roadmap document, just like the download page we’ll have a past, current and future releases structure. The current release pages are imported in the main roadmap page to get better Roadmap.

A single release page will contain at the very least:

• a reference to the point person that will keep the roadmap up to date
• a reference to the point person (s) that will perform the packaging and the release
• a plain text description of the objectives for the release (to be reused in the release annoucements)
• a release date and a testing freeze date
• a set of major items the testing team should verify (areas the developers suspect might contain bugs)
• links to the issues already fixed, resolved (but to be verified) and closed

For each release cycle two new people will be appointed to be:

• roadmap manager, the responsible for keeping the roadmap up to date
• release manager, the responsible for the release packaging
• release team, the people who should actually perform the release packaging. The release manager is the lead of the team and he should be the sole interface between the release team and the rest of the world

These three figures might end up being the same person, and the same person can cover the roles for various months, thought it’s advisable to see some turnover in those roles so that the load is shared (PSC members in particular are invited to share these responsibilities).

Each release announcement should thank the people doing the actual work, and the company (companies that allowed them to work on the release, if there was one.

The roadmap manager will perform a weekly update of the wiki page. In particular, this person will summarize the significant changes occurred during the week in a mail, check for outstanding work that has not been complete, and update the wiki page accordingly. The same update will be sent to the developer list so that all people subscribed to the list have an idea of what is going on. It is assumed that people will also answer about questions made by the roadmap manager (two way collaboration, the manager summarizes the status for everybody, everybody else helps the manager with information about outstanding bugs/features).

The release manager is responsible for warning the testing team and the developer team about the testing freeze, run the CITE tests (and report about failures) and of course do the actual packaging of the release on the assigned date. The release will be performed if there is no outstanding regression found by the testing team. In case regressions are found the package manager, the roadmap manager and the community will discuss about an alternate release date.

It is suggested that stable releases occur once every one month, but the actual timings will take into consideration the availability of a release manager, the current pace of development, the scheduling of funded features and critical bug fixes.

Once a release series enter maintenance mode, that is, when full development moves to another branch, a longer interval will be used (two to six months ideally), and the series will be eventually become unsupported as resources to work on that branch dry up completely. Each stable release will use a one week freeze and testing period.

New series will see a cycle with periodic betas , up until the developers feel comfortable calling the release a Release Candidate . The release candidate is a release that is considered solid enough to be re-released as final as is, without changes. As such, the RC will be subjected to a week of testing like a stable release.. Once the RC is out an announcement will ask every use to test it out thoroughly, feedback will be gathered, and if major show stoppers pop up, another release will be made, weekly, until no more issues are found. The last RC released this way will be re-released as final.

This section should contain feedback provided by PSC members who may have a problem with the proposal.

State here any backwards compatibility issues.

Andrea Aime: Alessio Fabiani Justin Deoliveira: Jody Garnett: Simone Giannecchini: Rob Atkinson:

JIRA Task Email Discussion Wiki Page