First GDAL Meeting

Date: Tuesday, Nov 20, 2007

Time: 1900 GMT is 1PM Central or 2PM Eastern (​world clock)

Place: #gdal on irc.freenode.net

Agenda

• Select Chair and Secretary

• Non Release Related
  • Migrate DWGDXF driver out of trunk.
  • Approve SponsorshipSurvey
  • Incubation Status

• Release process
  • Do we want a more formalized process, ala MapServer, with freezes and sequential betas, etc? RFC Freeze?
  • Feature Freeze?
  • Release Manager?
  • Ticket referencing restriction for commits (ie post-commit hook that requires a ticket number in the commit comment) during beta period?

• Outstanding development
  • Work that *must* make it into 1.5
  • Work that it would be nice to have done in time for 1.5
  • Bugs/features marked for 1.5 in Trac that can be deferred

• Release Timeline
  • Select optimistic 1st beta and final release dates.

• Documentation
  • For 1.5, should we consider a documentation snapshot that can stay sync'd with the stable 1.5 branch once it is out?
  • Do we need a doc similar to MapServer's migration doc to highlight significant and backward incompatible changes that 1.5 introduces?
  • What have you committed for 1.5? Frank's a great human ChangeLog generator, but it's a big task. Let's try and lessen its size.

Meeting Minutes

Non-Release Topics

DWGDXF Driver Out of Trunk

This is the last license issue left, copied from libraries that are non-open and should be migrated to /spike.

The driver depends on the ODA libraries, as such is generally not distributed in any distro binaries. Driver only supports writing and there are no alternatives at this time.

Could be rewritten, lots of work.

Motion: to move DWGDXF into /spike, out of trunk. carried

Approval of the Sponsorship Survey

Survey has been disclosed, and some updates have been made. Want to be able to distribute to sponsors.

Motion: approve sponsorship survey. carried

Incubation Status

GDAL is currently being held up by the provenance review and the dxfdwg item being the final actual issue. Hopefully will be ready for incubation with the release of GDAL 1.5.0.

GDAL currently meet all other criteria, as far as it is known.

Perhaps formalizing the release process would be prudent to expedite this, though there is a process whereby the PSC must approve the move from RC to a final release.

Should GDAL expect to be graduated at the next board meeting? It might be appropriate to request graduation from the incubation committee as of the release of 1.5. Current release (1.4) has license violations as of now. EPSG licensing issues have been settled as well through some refactoring.

GDAL 1.5.0 Issues

Release Process

Perhaps model something after the MapServer RFC 34 (Release Process), as seen at ​http://mapserver.gis.umn.edu/development/rfc/ms-rfc-34/. While all the steps are not appropriate for GDAL, it could be seen as a model.

Some goals would be

• Freeze period before a release
• Creation of a release manager position
• Maximize ABI compatibility in point-releases

Item 3 would require definition of an internal vs. external APIs.

Note that the 1.5.0 ABI will not be compatible with 1.4.x, but 1.5.1 will be backwards compatible with 1.5.0. This will ensure plugins through the 1.5.x release series will be compatible with all the various point releases, as well make upgrading GDAL for pre-built apps a lot easier.

Frank Warmerdam is not convinced we need something as comprehensive as MapServer's RFC 34. A code RFC freeze should be a precondition for entering the beta process, however.

Howard Butler to collect thoughts on Release Process RFC on the wiki and motion for approval on the gdal-dev mailing list.

Mateusz Loskot suggested a bug list freeze. Frank and Daniel both are against this, as it is the release manager's obligation to cut when there are no critical bugs in an RC.

Post-Commit Hook

A post-commit hook enforcing a ticket number on svn is not something Frank Warmerdam would like.

Howard Butler retracted his suggestion.

Daniel Morissette suggested that clear guidelines in the release process RFC should be set out, and public wrist slaps should be given to those who ignore the rules.

Release Manager

Motion: For the GDAL 1.4.4 Release, designate Howard Butler as the Release Manager. carried

Motion: For the GDAL 1.5.0 Release, designate Frank Warmerdam as the Release Manager. carried

Note that the role of the release manager is to be that as set out in the MapServer RFC 34 until GDAL establishes its own process.

Outstanding Development

Frank Warmerdam feels a need to rework how GDAL uses libtiff to do in-place update of files. As well wants to reincarnate the OGR Thread Safety RFC, though this might be a 1.6 release issue.

Howard Butler expects to add missing method to the next-gen Python bindings, as well as GeoJSON OGRGeometry I/O and finally add --enable-debug to the ./configure.

Andrey Kiselev is planning to complete gridding support in GDAL and add a user application to do that. Also wants to fix some outstanding HDF issues.

Daniel Morissette would like to add OGRStyle functions to the C API.

Chris Condit wants to update the KML writer to support KML 2.1.

Ari Jolma wants to finish improvements to the Perl API.

Klokan Petr Prindal thinks GDAL2Tiles should use the new TMS driver from OpenLayers 2.5

Motion: Howard Butler motioned to have an RFC freeze November 28th at UTC 0000. carried

Bugs for 1.5.0 Release

Frank will go through the 1.5 milestone bugs and set the priorities for the bugs as is appropriate.

Release Timeline

Motion: Beta Target for GDAL 1.5.0 release: 2007-12-03. carried By this point disruptive changes should all be complete.

Any noteworthy ABI changes should be discussed with the release manager, post Beta 1.

Frank has suggested that the 1.6 release would be 8-10 months after the 1.5 release.

Documentation

Documentation Snapshot

HTML Documentation Snapshot is provided with the x.y.0 releases as is. Is this not sufficient?

Howard Butler proposes browsable on the web, and active documentation until a new release is made.

It was proposed that docs be archived and made available at some point on the website.

Migration Document

Because GDAL's goal is to maximize backwards compatibility, a migration document should be minimal. The NEWS file should highlight any major release issues, as a migration document should indicate what is needed to migrate systems to the newest release.

Howard suggests that a wiki document should detail changes in the Python bindings.

Frank urges committers to use meaningful changelog messages, and that there should be a NEWS review stage where developers look at the NEWS file and point out omissions and inaccuracies.

Adjournment

Motion: Another release-oriented meeting on 2007-12-04. carried

Meeting was adjourned.