Skip to content

GeoServer Incubation Checklist

Jump to bottom Edit New page
jdeolive edited this page Jun 11, 2014 · 1 revision

GeoServer Incubation Checklist

Page to be filled in based on: Project Graduation Checklist .

Incubation Checklist

Open

\1. Open: projects are expected to function in an open and public manner and include:

  • (/) Open source license (s): GPL
  • (/) Open communication channels: geoserver-devel, geoserver-user, issue tracker
  • (/) Open decision making process: public change control (GeoServer Improvement Process), bi-weekly cross project meetings

\2. Active and healthy community:

  • (/) The project should have a community of developers and users who actively collaborate and support each other in a healthy way.

    • Collaboration on latest GeoServer 2.2 Release
    • Recent addition of geoserver-user rep to PSC

  • (/) Long term viability of the project is demonstrated by showing participation and direction from multiple developers, who come from multiple organisations.

    • Yes, project is held by neutral party under direction of a project steering committee. A range of organisations are represented and participate in the project, spanning from commercial companies, research institutes and individuals.

Copyright and License

\1. (/) All project source code is available under an Open Source license. 2. (/) Project documentation is available under an open license. 3. (/) The project code, documentation and data has been adequately vetted to assure it is all properly licensed, and a copyright notice included: [GeoServer Provenance Review] 4. (/) The project maintains a list of all copyright holders identified in the Provenance Review Document. 5. (/) All code contributors have agreed to abide by the project’s license policy, and this agreement has been documented and archived.

Process

\1. (/) The project has code under configuration management: http://github.com/geoserver 2. (/) The project uses an issue tracker and keeps the status of the issue tracker up to date: http://jira.codehaus.org/browse/GEOS 3. (/) The project has documented its management processes: http://docs.geoserver.org/stable/en/developer/

Documentation

\1. The project has user documentation

\2. The project has developer documentation: Geoserver Developers Manual

  • (/) Including checkout and build instructions: Quickstart

  • (/) Including commented code, ideally published for developer use.

Each release Stable has API Documentation download, and Source Code download archives.

  • (/) Providing sufficient detail for an experience programmer to contribute patches or a new module in accordance with the project’s programming conventions.

Developers Manual includes Policies and Procedures covers the nuts and bolts of committing, submitting patches, code reviews. Community process including formal GSIP change control and the functioning of the steering committee.

There is a relaxed community module sandbox to foster new developers.

Release Procedure

\1. The project follows a defined release process:

We have long maintained a Release Guide , recently this has been improved with automated release scripts which can be executed on our build box.

  • (/) Which includes execution of the testing process before releasing a stable release.

We have a Release Testing Checklist and CITE Test Guide , moreover the continuous build server builds GeoServer and runs the build tests whenever a new commit is spotted in the revision control.

\2. The project follows a documented testing process.

  • (/) Ideally, this includes both automated and manual testing

The build box (http://hudson.opengeo.org/hudson/) contains automated testing as part of the build process.

In addition integration tests with databases are available, and CITE conformance tests.

  • (/) Ideally this includes documented conformance to set quality goals, such as reporting Percentage Code Coverage of Unit Tests.

Test coverage of 40% is required for a community module to be promoted for formal inclusion in the application.

CITE test conformance is required for release.

All large modifications, as well as any contribution outside of the core developer circle are subject to peer review.

\3. Release and testing processes provide sufficient detail for an experienced programmer to follow.

(/) The Developers Manual includes the section Release Guide documenting how volunteers can step up and make a release.

OSGeo Committees and Community

Board

\1. (/) Provide a Project Officer as a contract point: Andrea has accepted the nomination

Marketing

\1. (/) Marketing artefacts have been created about the project in line with the incubation criteria listed in the OSGeo Marketing Committee’s Marketing Artefacts.

\2. (/) Ideally, stable version (s) of executable applications are bundled with appropriate distributions.

Platform independent packages as well as Windows and OSX installers are build for every release, moreover platform independent packages are built every night and made available to the user community for testing. * http://live.osgeo.org/en/overview/geoserver_overview.html

Projects

(/) Projects do not exist in isolation; and are expected to communicate and collaborate on key issues.

  • GeoServer has bi-weekly meetings with the GeoTools project
  • uDig releases are tested against the latest GeoServer
  • PostGIS release procedure tests against GeoServer

SAC

\1. (/) The following should be set up: http://geoserver.osgeo.org domain name

  • The osgeo.org website links to geoserver.org

\2. (/) A project may optionally request SAC help to make use of:

  • OSGeo issue tracker - not requested
  • OSGeo mailing list - not requested
  • OSGeo svn - not requested
  • http://downloads.osgeo.org - not requested
Add a custom footer

Home
Proposals
Release Schedule

Clone this wiki locally