[Geoserver-devel] PSC Meeting Minuets, August 25th 2015

GeoTools / GeoServer Meeting 2015-08-25

Attending

Jody Garnett
Kevin Smith
Andrea Aime

Agenda

Maintenance Release
Recent Pull Reqeusts
Beta Release
Transformations in CSS

Actions

  • Jody: release GeoServer 2.8-beta (et al)
  • Jody / Victoria Office: release GeoServer 2.6.5 (et al)
  • Andrea: add two liners docs to GeoTools for sortByGroup

Mainteance Release

Scheduled for this week, woudl like to get it out Thrusday.

Blocked pending backport of white list fix:

  • Kevin wrote that some tests were failing (on the backport).
  • Andrea has likely no time to help with the backport it by Thursday

Ask Kevin to look at it Wednesday.

Recent Pull requests

The following pull request have been merged, but may warrent further discussion.

  1. Constrast enhancement

Merged by Simone, some odd whitespace, still waiting on docs.

Action: Contact Simone with respect to docs (cut and paste from proposal :smiley: )

  1. z-order

Review/merged went smoothly.

Docs showing up in both geotools and geoserver:

http://docs.geoserver.org/latest/en/user/styling/sld-extensions/z-order/example.html

  • sld section includes css examples (huh)?

http://docs.geotools.org/latest/userguide/library/render/style.html#featuretypestyle

  • missing documentation on sort group
  1. ResourceStore API Change

Niels had a busted test, fixed and merged to master (but may get some feedback from Niels).

  1. Rewrite of ArcGIS compact cache code and support for ArcGIS 10.3 compact caches
  • Merged after adjusting dependencies to reduce bloat.
  1. Style generation

Merged without REST API (will have to be added later).

Beta Release

Scheduled for this week (Friday). This is a beta release resulting in a feature freezse.

The real question is which pull requests are going to make the cut.

  1. Improvement to label cache from IGN. To be reviewed. https://github.com/geotools/geotools/pull/948

Sounds cool - is it an API change (if so priority).

  1. New projection, Meteosat 2 one, https://github.com/geotools/geotools/pull/947/files

  2. GeodeticCalculator rewrite on geographic lib: https://github.com/geotools/geotools/pull/945

  3. Dasharry property expressions: https://github.com/geotools/geotools/pull/943 (not sure)
    Jody should review, it is a priority due to api change.
    Waiting on response to Andrea’s review… whitespace / headers / docs.

  4. Not a pull request yet, but expressions for inline content (not the right way imho)
    Andrea will provide feedback, looks like it may be more complicated that needed.

  5. WPS improvements in GeoServer pull requests. To be reviewed, sort of stuck

These are waiting on feedback, may not make the cut if authors do not respond.

  1. jai-ext disabled by default (pr to be made)
    jai-ext results in slow down so - disable by default. UI is already available to enable/disable operation by operation (as needed for deployment).
    Will gradually improve performance before making this the default.

  2. Separate panels for layer defaults and general caching options
    Jody following up with Kevin.

  3. Allow ExternalGraphic image to be used for GetCapabilities and GetLegendGraphics
    Kevin will review :stuck_out_tongue:

Action: Jody will send email about the older pull requests (WPS Process Refactoring)

Transformations in CSS

Asked feedback to add support to rendering transformation of CSS.

This is a balance between passing in parameters (where name matters), and representing as functions (where position matters).

Jody likes example (c) - it is nested but communicates the names:

ras:Contour(data(), levels(1100, 1200, 1300, 1400))) {
stroke: black;
}

http://stackoverflow.com/questions/4914533/do-css-functions-exist :slight_smile:

-----Original Message-----
From: Jody Garnett [mailto:jody.garnett@…403…]
Sent: 25 August 2015 21:07
To: Geoserver-devel <geoserver-devel@lists.sourceforge.net>
Subject: [Geoserver-devel] PSC Meeting Minuets, August 25th 2015

GeoTools / GeoServer Meeting 2015-08-25

The real question is which pull requests are going to make the cut.

Is https://github.com/geoserver/geoserver/pull/1191 - "Add option to disable INSPIRE capabilities" on the list for consideration?

I'd like to add another one to address https://osgeo-org.atlassian.net/browse/GEOS-6435 - "Add INSPIRE extended capabilities section to WCS GetCapabilities response" but my code for that builds on top of 1191 so I can't really submit it as a pull request until/if 1191 is merged I guess.

A related general question... When master goes ahead of the commit on which a pull request I submitted was based, is it best practice for me to rebase the pull request branch on top of the latest master and checking the build whenever I notice commits to master?

Marcus Sen
British Geological Survey
Keyworth
Nottingham
NG12 5GG

Web: http://www.bgs.ac.uk

________________________________
This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.
________________________________

Marcus,

tl;dr: I advise against rebasing published branches.

In my view, it is perfectly fine to leave your pull request alone if it still merges cleanly. Rebasing on every commit to master? That way madness lies.

Rebasing any published branch, even one made for a pull request, is rewriting history, and will prevent anyone from pulling from your branch (which I often do when reviewing). Reviewers are quite capable of cherry-picking if required. Also, rebasing changes the branch so it no longer matches the comments in the pull request. Pull requests are associated with branches by name not by their commit id.

On the other hand, there are some developers who rebase to keep their pull-request branches clean. While this does make their requests tidy, git does not require this practice.

If I have made a terrible mess, I prefer to close a pull request and make a new branch and pull request, rather than rebase. This seems more transparent to me, and preserves the relevance of existing comments.

Kind regards,
Ben.

On 26/08/15 22:14, Sen, Marcus A. wrote:

A related general question... When master goes ahead of the commit on which a pull request I submitted was based, is it best practice for me to rebase the pull request branch on top of the latest master and checking the build whenever I notice commits to master?

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand