[Geoserver-devel] Build failures on master

GeoServer GeoServer Developer
1

Hi all,

I’m seeing some build failures on master now. After sniffing around a bit, I see that the “usa” coverage dataset that is used in several tests is not being configured properly on my machine.

I dug into it a bit further and found that “usa” is a worldimage dataset stored in a ZIP archive and unpacked automatically when setting up for tests. I would expect that the WorldImage coverage reader would be used for this, but because of the way the MockData class is implemented we pass the directory as the path to the coverage data instead of the path to the image file (a PNG in this case.) But WorldImage requires that the file extension correspond to one of the image file types it supports and doesn’t take directories.

So I’m not sure how this is supposed to be working - is it possible that ImageMosaic is being used for this? I don’t see why it would fail on (just) my machine in that case though. Any thoughts on what I should do next in terms of troubleshooting would be appreciated.

–
David Winslow
OpenGeo - http://opengeo.org/

2

After digging on this for a while, I found that my system was configured oddly - I have a custom hostname but it wasn’t registered in my /etc/hosts file, leading to some weird errors in a few places in the Java standard library. (I have encountered related issues where “localhost” wasn’t properly registered, or else I would probably still be investigating!)

Anyway, I ended up more time than seems necessary because of some exceptions being silently swallowed in GeoTools code. I issued a pull request against the new Github repo: https://github.com/geotools/geotools/pull/3

I also made a patch against GeoServer. Even though it wasn’t causing my failure, it seems like there are some places in GeoServer where we rely on a directory containing a single image being used as a single-tile imagemosaic instead of using a more specific coveragestore. I think it makes things a bit cleaner to use the more specific type where it’s known: https://github.com/geoserver/geoserver/pull/4

I also beefed up the error reporting when setting up coverages - I don’t think this is changing API or behavior much so I went ahead and put it in the master branch. https://github.com/geoserver/geoserver/commit/f8711050b3c308a046e4c432b004737fc674efb9

–
David Winslow
OpenGeo - http://opengeo.org/

On Tue, Jul 10, 2012 at 11:33 AM, David Winslow <dwinslow@anonymised.com1…> wrote:

Hi all,

I’m seeing some build failures on master now. After sniffing around a bit, I see that the “usa” coverage dataset that is used in several tests is not being configured properly on my machine.

I dug into it a bit further and found that “usa” is a worldimage dataset stored in a ZIP archive and unpacked automatically when setting up for tests. I would expect that the WorldImage coverage reader would be used for this, but because of the way the MockData class is implemented we pass the directory as the path to the coverage data instead of the path to the image file (a PNG in this case.) But WorldImage requires that the file extension correspond to one of the image file types it supports and doesn’t take directories.

So I’m not sure how this is supposed to be working - is it possible that ImageMosaic is being used for this? I don’t see why it would fail on (just) my machine in that case though. Any thoughts on what I should do next in terms of troubleshooting would be appreciated.

–
David Winslow
OpenGeo - http://opengeo.org/

3

Pull requests are a separate issue (mentioned at Monday's meeting). Possibly because GeoServer is a GitHib organisation, nobody gets notified about pull requests (I have heard mixed reports between GT and GS).

Have you created a GEOS Jira issue for the pull request? This might be the most robust and traceable process.

Anyone have a best-practice to recommend?

On 11/07/12 08:32, David Winslow wrote:

Anyway, I ended up more time than seems necessary because of some
exceptions being silently swallowed in GeoTools code. I issued a pull
request against the new Github repo:
https://github.com/geotools/geotools/pull/3
I also made a patch against GeoServer. Even though it wasn't causing my
failure, it seems like there are some places in GeoServer where we rely
on a directory containing a single image being used as a single-tile
imagemosaic instead of using a more specific coveragestore. I think it
makes things a bit cleaner to use the more specific type where it's
known: https://github.com/geoserver/geoserver/pull/4

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

4

Glad you sorted this out David.

On Tue, Jul 10, 2012 at 6:32 PM, David Winslow <dwinslow@anonymised.com> wrote:

After digging on this for a while, I found that my system was configured oddly - I have a custom hostname but it wasn’t registered in my /etc/hosts file, leading to some weird errors in a few places in the Java standard library. (I have encountered related issues where “localhost” wasn’t properly registered, or else I would probably still be investigating!)

Anyway, I ended up more time than seems necessary because of some exceptions being silently swallowed in GeoTools code. I issued a pull request against the new Github repo: https://github.com/geotools/geotools/pull/3

Commented on it but really a module i don’t; maintain so will leave it to others. Regarding pull requests unfortunately I haven;t been able to find a way to set up notifications for them so they kind of go unseen. Going to send another email about this.

I also made a patch against GeoServer. Even though it wasn’t causing my failure, it seems like there are some places in GeoServer where we rely on a directory containing a single image being used as a single-tile imagemosaic instead of using a more specific coveragestore. I think it makes things a bit cleaner to use the more specific type where it’s known: https://github.com/geoserver/geoserver/pull/4

Seems reasonable to me. You can confirm the full set of tests pass with the patch applied? If you can verify i say let;s merge it in.

I also beefed up the error reporting when setting up coverages - I don’t think this is changing API or behavior much so I went ahead and put it in the master branch. https://github.com/geoserver/geoserver/commit/f8711050b3c308a046e4c432b004737fc674efb9

–
David Winslow
OpenGeo - http://opengeo.org/

On Tue, Jul 10, 2012 at 11:33 AM, David Winslow <dwinslow@anonymised.com> wrote:

Hi all,

I’m seeing some build failures on master now. After sniffing around a bit, I see that the “usa” coverage dataset that is used in several tests is not being configured properly on my machine.

I dug into it a bit further and found that “usa” is a worldimage dataset stored in a ZIP archive and unpacked automatically when setting up for tests. I would expect that the WorldImage coverage reader would be used for this, but because of the way the MockData class is implemented we pass the directory as the path to the coverage data instead of the path to the image file (a PNG in this case.) But WorldImage requires that the file extension correspond to one of the image file types it supports and doesn’t take directories.

So I’m not sure how this is supposed to be working - is it possible that ImageMosaic is being used for this? I don’t see why it would fail on (just) my machine in that case though. Any thoughts on what I should do next in terms of troubleshooting would be appreciated.

–
David Winslow
OpenGeo - http://opengeo.org/

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

5

Ha, you beat me to it Ben. Was just going to mention that our current policy for pull requests is to file a jira alongside a pull request so devs get the notification. However, I think i found the reason why we are not getting notified and its described here:

http://alexking.org/blog/2011/11/28/not-getting-github-notifications

Myself, yourself, Andrea, and Jody were in the owners group and not the individual team groups. I figured one encompassed the other but i guess not when it comes to notifications. I confirmed with Gabriel that he does indeed get the pull request notifications.

So I wonder… do we still need a jira to accompany a pull request? I am tempted to say no since it would seem to be needless overhead but there is the downside of the changelog not containing such patches. Tough call. Interested in hearing what other folks think.

On Tue, Jul 10, 2012 at 7:43 PM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

Pull requests are a separate issue (mentioned at Monday’s meeting).
Possibly because GeoServer is a GitHib organisation, nobody gets
notified about pull requests (I have heard mixed reports between GT and GS).

Have you created a GEOS Jira issue for the pull request? This might be
the most robust and traceable process.

Anyone have a best-practice to recommend?

On 11/07/12 08:32, David Winslow wrote:

Anyway, I ended up more time than seems necessary because of some
exceptions being silently swallowed in GeoTools code. I issued a pull
request against the new Github repo:
https://github.com/geotools/geotools/pull/3
I also made a patch against GeoServer. Even though it wasn’t causing my
failure, it seems like there are some places in GeoServer where we rely
on a directory containing a single image being used as a single-tile
imagemosaic instead of using a more specific coveragestore. I think it
makes things a bit cleaner to use the more specific type where it’s
known: https://github.com/geoserver/geoserver/pull/4

–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

6

I also am getting pull requests. I think for many casual uses (documentation fixes and so on) that a pull request is fine. It amounts to a light code review by another set of eyes.

For anything more significant (fixes, new features, etc…) JIRA is really useful; and we can consider mentioning a pull request in Jira (as a nicer alternative to a patch)

(This is consistent with how uDig is using Jira and GitHub; I note however that we often leave pull requests to die on the vine if any issues are not promptly sorted out)

–
Jody Garnett

On Wednesday, 11 July 2012 at 11:58 AM, Justin Deoliveira wrote:

Ha, you beat me to it Ben. Was just going to mention that our current policy for pull requests is to file a jira alongside a pull request so devs get the notification. However, I think i found the reason why we are not getting notified and its described here:

http://alexking.org/blog/2011/11/28/not-getting-github-notifications

Myself, yourself, Andrea, and Jody were in the owners group and not the individual team groups. I figured one encompassed the other but i guess not when it comes to notifications. I confirmed with Gabriel that he does indeed get the pull request notifications.

So I wonder… do we still need a jira to accompany a pull request? I am tempted to say no since it would seem to be needless overhead but there is the downside of the changelog not containing such patches. Tough call. Interested in hearing what other folks think.

On Tue, Jul 10, 2012 at 7:43 PM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

Pull requests are a separate issue (mentioned at Monday’s meeting).
Possibly because GeoServer is a GitHib organisation, nobody gets
notified about pull requests (I have heard mixed reports between GT and GS).

Have you created a GEOS Jira issue for the pull request? This might be
the most robust and traceable process.

Anyone have a best-practice to recommend?

On 11/07/12 08:32, David Winslow wrote:

Anyway, I ended up more time than seems necessary because of some
exceptions being silently swallowed in GeoTools code. I issued a pull
request against the new Github repo:
https://github.com/geotools/geotools/pull/3
I also made a patch against GeoServer. Even though it wasn’t causing my
failure, it seems like there are some places in GeoServer where we rely
on a directory containing a single image being used as a single-tile
imagemosaic instead of using a more specific coveragestore. I think it
makes things a bit cleaner to use the more specific type where it’s
known: https://github.com/geoserver/geoserver/pull/4

–
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

7

Given that the pull request was not summarily merged, I guess this counts as “more significant.” I have created a JIRA issue: http://jira.codehaus.org/browse/GEOT-4199

–
David Winslow
OpenGeo - http://opengeo.org/

On Wed, Jul 11, 2012 at 2:50 AM, Jody Garnett <jody.garnett@anonymised.com…> wrote:

I also am getting pull requests. I think for many casual uses (documentation fixes and so on) that a pull request is fine. It amounts to a light code review by another set of eyes.

For anything more significant (fixes, new features, etc…) JIRA is really useful; and we can consider mentioning a pull request in Jira (as a nicer alternative to a patch)

(This is consistent with how uDig is using Jira and GitHub; I note however that we often leave pull requests to die on the vine if any issues are not promptly sorted out)

–
Jody Garnett

On Wednesday, 11 July 2012 at 11:58 AM, Justin Deoliveira wrote:

Ha, you beat me to it Ben. Was just going to mention that our current policy for pull requests is to file a jira alongside a pull request so devs get the notification. However, I think i found the reason why we are not getting notified and its described here:

http://alexking.org/blog/2011/11/28/not-getting-github-notifications

Myself, yourself, Andrea, and Jody were in the owners group and not the individual team groups. I figured one encompassed the other but i guess not when it comes to notifications. I confirmed with Gabriel that he does indeed get the pull request notifications.

So I wonder… do we still need a jira to accompany a pull request? I am tempted to say no since it would seem to be needless overhead but there is the downside of the changelog not containing such patches. Tough call. Interested in hearing what other folks think.

On Tue, Jul 10, 2012 at 7:43 PM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

Pull requests are a separate issue (mentioned at Monday’s meeting).
Possibly because GeoServer is a GitHib organisation, nobody gets
notified about pull requests (I have heard mixed reports between GT and GS).

Have you created a GEOS Jira issue for the pull request? This might be
the most robust and traceable process.

Anyone have a best-practice to recommend?

On 11/07/12 08:32, David Winslow wrote:

Anyway, I ended up more time than seems necessary because of some
exceptions being silently swallowed in GeoTools code. I issued a pull
request against the new Github repo:
https://github.com/geotools/geotools/pull/3
I also made a patch against GeoServer. Even though it wasn’t causing my
failure, it seems like there are some places in GeoServer where we rely
on a directory containing a single image being used as a single-tile
imagemosaic instead of using a more specific coveragestore. I think it
makes things a bit cleaner to use the more specific type where it’s
known: https://github.com/geoserver/geoserver/pull/4

–
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

8

On Tue, Jul 10, 2012 at 9:44 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Anyway, I ended up more time than seems necessary because of some exceptions being silently swallowed in GeoTools code. I issued a pull request against the new Github repo: https://github.com/geotools/geotools/pull/3

Commented on it but really a module i don’t; maintain so will leave it to others. Regarding pull requests unfortunately I haven;t been able to find a way to set up notifications for them so they kind of go unseen. Going to send another email about this.

I think we can take this up on the GeoTools list (note ticket at http://jira.codehaus.org/browse/GEOT-4199)

I also made a patch against GeoServer. Even though it wasn’t causing my failure, it seems like there are some places in GeoServer where we rely on a directory containing a single image being used as a single-tile imagemosaic instead of using a more specific coveragestore. I think it makes things a bit cleaner to use the more specific type where it’s known: https://github.com/geoserver/geoserver/pull/4

Seems reasonable to me. You can confirm the full set of tests pass with the patch applied? If you can verify i say let;s merge it in.

They do pass so I did the merge. Of course, now that I write that I realize I never even compiled the extensions or community modules so the next Hudson build might complain…

–
David Winslow
OpenGeo - http://opengeo.org/

9

Morning David:

I got a question that keeps me from just hitting the “merge” option on github (which is the magic of pull requests).

Do we have an easy way to apply the “fix” to the older branches? Or is the author expecting the change to be applied to the older branches.

take 1:

Hit accept merge, and then cherry pick the resulting commit into the stable branch. This ignores doing a full build and so on …

take 2:

Accept the pull request manually; add you as a remote repository; grab the change onto my local machine; build and apply to master. And then repeat to build and apply on stable.

–

Jody Garnett

On Thursday, 12 July 2012 at 12:28 AM, David Winslow wrote:

Given that the pull request was not summarily merged, I guess this counts as “more significant.” I have created a JIRA issue: http://jira.codehaus.org/browse/GEOT-4199

–
David Winslow
OpenGeo - http://opengeo.org/

On Wed, Jul 11, 2012 at 2:50 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I also am getting pull requests. I think for many casual uses (documentation fixes and so on) that a pull request is fine. It amounts to a light code review by another set of eyes.

For anything more significant (fixes, new features, etc…) JIRA is really useful; and we can consider mentioning a pull request in Jira (as a nicer alternative to a patch)

(This is consistent with how uDig is using Jira and GitHub; I note however that we often leave pull requests to die on the vine if any issues are not promptly sorted out)

–
Jody Garnett

On Wednesday, 11 July 2012 at 11:58 AM, Justin Deoliveira wrote:

Ha, you beat me to it Ben. Was just going to mention that our current policy for pull requests is to file a jira alongside a pull request so devs get the notification. However, I think i found the reason why we are not getting notified and its described here:

http://alexking.org/blog/2011/11/28/not-getting-github-notifications

Myself, yourself, Andrea, and Jody were in the owners group and not the individual team groups. I figured one encompassed the other but i guess not when it comes to notifications. I confirmed with Gabriel that he does indeed get the pull request notifications.

So I wonder… do we still need a jira to accompany a pull request? I am tempted to say no since it would seem to be needless overhead but there is the downside of the changelog not containing such patches. Tough call. Interested in hearing what other folks think.

On Tue, Jul 10, 2012 at 7:43 PM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

Pull requests are a separate issue (mentioned at Monday’s meeting).
Possibly because GeoServer is a GitHib organisation, nobody gets
notified about pull requests (I have heard mixed reports between GT and GS).

Have you created a GEOS Jira issue for the pull request? This might be
the most robust and traceable process.

Anyone have a best-practice to recommend?

On 11/07/12 08:32, David Winslow wrote:

Anyway, I ended up more time than seems necessary because of some
exceptions being silently swallowed in GeoTools code. I issued a pull
request against the new Github repo:
https://github.com/geotools/geotools/pull/3
I also made a patch against GeoServer. Even though it wasn’t causing my
failure, it seems like there are some places in GeoServer where we rely
on a directory containing a single image being used as a single-tile
imagemosaic instead of using a more specific coveragestore. I think it
makes things a bit cleaner to use the more specific type where it’s
known: https://github.com/geoserver/geoserver/pull/4

–
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

10

Actually I rarely use the through-the-web merge tool on Github - for me the nice thing about pull requests is the ability to comment on the patch line-by-line, see new additions to the patch in the same comment thread, etc. Here’s a GeoNode pull request that used all that kind of stuff: https://github.com/GeoNode/geonode/pull/248

As far as applying changes to older branches, I think the easiest workflow in Git is to develop the changes against the oldest branch and then merge forward. But since the GeoTools repo is produced from git-svn this won’t work well, so cherry-picking or rebasing is the way to go. If you don’t want to add a remote for my repository you can just write:

git fetch git://github.com/dwins/geotools.git exception-swallowing-in-ImageMosaic

After that my branch will appear as a local one for you named FETCH_HEAD.

–
David Winslow
OpenGeo - http://opengeo.org/

On Wed, Jul 11, 2012 at 9:58 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Morning David:

I got a question that keeps me from just hitting the “merge” option on github (which is the magic of pull requests).

Do we have an easy way to apply the “fix” to the older branches? Or is the author expecting the change to be applied to the older branches.

take 1:

Hit accept merge, and then cherry pick the resulting commit into the stable branch. This ignores doing a full build and so on …

take 2:

Accept the pull request manually; add you as a remote repository; grab the change onto my local machine; build and apply to master. And then repeat to build and apply on stable.

–

Jody Garnett

On Thursday, 12 July 2012 at 12:28 AM, David Winslow wrote:

Given that the pull request was not summarily merged, I guess this counts as “more significant.” I have created a JIRA issue: http://jira.codehaus.org/browse/GEOT-4199

–
David Winslow
OpenGeo - http://opengeo.org/

On Wed, Jul 11, 2012 at 2:50 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I also am getting pull requests. I think for many casual uses (documentation fixes and so on) that a pull request is fine. It amounts to a light code review by another set of eyes.

For anything more significant (fixes, new features, etc…) JIRA is really useful; and we can consider mentioning a pull request in Jira (as a nicer alternative to a patch)

(This is consistent with how uDig is using Jira and GitHub; I note however that we often leave pull requests to die on the vine if any issues are not promptly sorted out)

–
Jody Garnett

On Wednesday, 11 July 2012 at 11:58 AM, Justin Deoliveira wrote:

Ha, you beat me to it Ben. Was just going to mention that our current policy for pull requests is to file a jira alongside a pull request so devs get the notification. However, I think i found the reason why we are not getting notified and its described here:

http://alexking.org/blog/2011/11/28/not-getting-github-notifications

Myself, yourself, Andrea, and Jody were in the owners group and not the individual team groups. I figured one encompassed the other but i guess not when it comes to notifications. I confirmed with Gabriel that he does indeed get the pull request notifications.

So I wonder… do we still need a jira to accompany a pull request? I am tempted to say no since it would seem to be needless overhead but there is the downside of the changelog not containing such patches. Tough call. Interested in hearing what other folks think.

On Tue, Jul 10, 2012 at 7:43 PM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

Pull requests are a separate issue (mentioned at Monday’s meeting).
Possibly because GeoServer is a GitHib organisation, nobody gets
notified about pull requests (I have heard mixed reports between GT and GS).

Have you created a GEOS Jira issue for the pull request? This might be
the most robust and traceable process.

Anyone have a best-practice to recommend?

On 11/07/12 08:32, David Winslow wrote:

Anyway, I ended up more time than seems necessary because of some
exceptions being silently swallowed in GeoTools code. I issued a pull
request against the new Github repo:
https://github.com/geotools/geotools/pull/3
I also made a patch against GeoServer. Even though it wasn’t causing my
failure, it seems like there are some places in GeoServer where we rely
on a directory containing a single image being used as a single-tile
imagemosaic instead of using a more specific coveragestore. I think it
makes things a bit cleaner to use the more specific type where it’s
known: https://github.com/geoserver/geoserver/pull/4

–
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

11

On Thu, Jul 12, 2012 at 8:18 AM, David Winslow <dwinslow@anonymised.com> wrote:

Actually I rarely use the through-the-web merge tool on Github - for me the nice thing about pull requests is the ability to comment on the patch line-by-line, see new additions to the patch in the same comment thread, etc. Here’s a GeoNode pull request that used all that kind of stuff: https://github.com/GeoNode/geonode/pull/248

Interesting. So how do you merge in pull requests? Add the developers repo as a remote and pull down the changes that way?

As far as applying changes to older branches, I think the easiest workflow in Git is to develop the changes against the oldest branch and then merge forward. But since the GeoTools repo is produced from git-svn this won’t work well, so cherry-picking or rebasing is the way to go. If you don’t want to add a remote for my repository you can just write:

Even if the branches did have a shared history a merge would be tricky as the branches do diverge. But then again cherry-picking also often results in conflicts so maybe it would be easier.

git fetch git://github.com/dwins/geotools.git exception-swallowing-in-ImageMosaic

After that my branch will appear as a local one for you named FETCH_HEAD.

Nice! Will have to remember this.

–
David Winslow
OpenGeo - http://opengeo.org/

On Wed, Jul 11, 2012 at 9:58 PM, Jody Garnett <jody.garnett@anonymised.com3…> wrote:

Morning David:

I got a question that keeps me from just hitting the “merge” option on github (which is the magic of pull requests).

Do we have an easy way to apply the “fix” to the older branches? Or is the author expecting the change to be applied to the older branches.

take 1:

Hit accept merge, and then cherry pick the resulting commit into the stable branch. This ignores doing a full build and so on …

take 2:

Accept the pull request manually; add you as a remote repository; grab the change onto my local machine; build and apply to master. And then repeat to build and apply on stable.

–

Jody Garnett

On Thursday, 12 July 2012 at 12:28 AM, David Winslow wrote:

Given that the pull request was not summarily merged, I guess this counts as “more significant.” I have created a JIRA issue: http://jira.codehaus.org/browse/GEOT-4199

–
David Winslow
OpenGeo - http://opengeo.org/

On Wed, Jul 11, 2012 at 2:50 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I also am getting pull requests. I think for many casual uses (documentation fixes and so on) that a pull request is fine. It amounts to a light code review by another set of eyes.

For anything more significant (fixes, new features, etc…) JIRA is really useful; and we can consider mentioning a pull request in Jira (as a nicer alternative to a patch)

(This is consistent with how uDig is using Jira and GitHub; I note however that we often leave pull requests to die on the vine if any issues are not promptly sorted out)

–
Jody Garnett

On Wednesday, 11 July 2012 at 11:58 AM, Justin Deoliveira wrote:

Ha, you beat me to it Ben. Was just going to mention that our current policy for pull requests is to file a jira alongside a pull request so devs get the notification. However, I think i found the reason why we are not getting notified and its described here:

http://alexking.org/blog/2011/11/28/not-getting-github-notifications

Myself, yourself, Andrea, and Jody were in the owners group and not the individual team groups. I figured one encompassed the other but i guess not when it comes to notifications. I confirmed with Gabriel that he does indeed get the pull request notifications.

So I wonder… do we still need a jira to accompany a pull request? I am tempted to say no since it would seem to be needless overhead but there is the downside of the changelog not containing such patches. Tough call. Interested in hearing what other folks think.

On Tue, Jul 10, 2012 at 7:43 PM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

Pull requests are a separate issue (mentioned at Monday’s meeting).
Possibly because GeoServer is a GitHib organisation, nobody gets
notified about pull requests (I have heard mixed reports between GT and GS).

Have you created a GEOS Jira issue for the pull request? This might be
the most robust and traceable process.

Anyone have a best-practice to recommend?

On 11/07/12 08:32, David Winslow wrote:

Anyway, I ended up more time than seems necessary because of some
exceptions being silently swallowed in GeoTools code. I issued a pull
request against the new Github repo:
https://github.com/geotools/geotools/pull/3
I also made a patch against GeoServer. Even though it wasn’t causing my
failure, it seems like there are some places in GeoServer where we rely
on a directory containing a single image being used as a single-tile
imagemosaic instead of using a more specific coveragestore. I think it
makes things a bit cleaner to use the more specific type where it’s
known: https://github.com/geoserver/geoserver/pull/4

–
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

12

On Thu, Jul 12, 2012 at 10:38 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

On Thu, Jul 12, 2012 at 8:18 AM, David Winslow <dwinslow@anonymised.com> wrote:

Actually I rarely use the through-the-web merge tool on Github - for me the nice thing about pull requests is the ability to comment on the patch line-by-line, see new additions to the patch in the same comment thread, etc. Here’s a GeoNode pull request that used all that kind of stuff: https://github.com/GeoNode/geonode/pull/248

Interesting. So how do you merge in pull requests? Add the developers repo as a remote and pull down the changes that way?

Yes. Github will automatically close the pull request if a merge is pushed to the repository. I should clarify that it’s not that I don’t trust the online merge tool, I just prefer to merge locally and run the tests if code is affected.

As far as applying changes to older branches, I think the easiest workflow in Git is to develop the changes against the oldest branch and then merge forward. But since the GeoTools repo is produced from git-svn this won’t work well, so cherry-picking or rebasing is the way to go. If you don’t want to add a remote for my repository you can just write:

Even if the branches did have a shared history a merge would be tricky as the branches do diverge. But then again cherry-picking also often results in conflicts so maybe it would be easier.

I think fully going with the flow here would require making the release branch (8.x) fully behind master - that is, most of the time, merging 8.x onto master should be a no-op. See http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html ; particularly the sections labelled ‘Graduation’ and ‘Merging upwards.’ If you don’t work that way then you will end up having to rebase/cherry-pick to duplicate changes across branches.

git fetch git://github.com/dwins/geotools.git exception-swallowing-in-ImageMosaic

After that my branch will appear as a local one for you named FETCH_HEAD.

Nice! Will have to remember this.

–
David Winslow
OpenGeo - http://opengeo.org/

On Wed, Jul 11, 2012 at 9:58 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Morning David:

I got a question that keeps me from just hitting the “merge” option on github (which is the magic of pull requests).

Do we have an easy way to apply the “fix” to the older branches? Or is the author expecting the change to be applied to the older branches.

take 1:

Hit accept merge, and then cherry pick the resulting commit into the stable branch. This ignores doing a full build and so on …

take 2:

Accept the pull request manually; add you as a remote repository; grab the change onto my local machine; build and apply to master. And then repeat to build and apply on stable.

–

Jody Garnett

On Thursday, 12 July 2012 at 12:28 AM, David Winslow wrote:

Given that the pull request was not summarily merged, I guess this counts as “more significant.” I have created a JIRA issue: http://jira.codehaus.org/browse/GEOT-4199

–
David Winslow
OpenGeo - http://opengeo.org/

On Wed, Jul 11, 2012 at 2:50 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I also am getting pull requests. I think for many casual uses (documentation fixes and so on) that a pull request is fine. It amounts to a light code review by another set of eyes.

For anything more significant (fixes, new features, etc…) JIRA is really useful; and we can consider mentioning a pull request in Jira (as a nicer alternative to a patch)

(This is consistent with how uDig is using Jira and GitHub; I note however that we often leave pull requests to die on the vine if any issues are not promptly sorted out)

–
Jody Garnett

On Wednesday, 11 July 2012 at 11:58 AM, Justin Deoliveira wrote:

Ha, you beat me to it Ben. Was just going to mention that our current policy for pull requests is to file a jira alongside a pull request so devs get the notification. However, I think i found the reason why we are not getting notified and its described here:

http://alexking.org/blog/2011/11/28/not-getting-github-notifications

Myself, yourself, Andrea, and Jody were in the owners group and not the individual team groups. I figured one encompassed the other but i guess not when it comes to notifications. I confirmed with Gabriel that he does indeed get the pull request notifications.

So I wonder… do we still need a jira to accompany a pull request? I am tempted to say no since it would seem to be needless overhead but there is the downside of the changelog not containing such patches. Tough call. Interested in hearing what other folks think.

On Tue, Jul 10, 2012 at 7:43 PM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

Pull requests are a separate issue (mentioned at Monday’s meeting).
Possibly because GeoServer is a GitHib organisation, nobody gets
notified about pull requests (I have heard mixed reports between GT and GS).

Have you created a GEOS Jira issue for the pull request? This might be
the most robust and traceable process.

Anyone have a best-practice to recommend?

On 11/07/12 08:32, David Winslow wrote:

Anyway, I ended up more time than seems necessary because of some
exceptions being silently swallowed in GeoTools code. I issued a pull
request against the new Github repo:
https://github.com/geotools/geotools/pull/3
I also made a patch against GeoServer. Even though it wasn’t causing my
failure, it seems like there are some places in GeoServer where we rely
on a directory containing a single image being used as a single-tile
imagemosaic instead of using a more specific coveragestore. I think it
makes things a bit cleaner to use the more specific type where it’s
known: https://github.com/geoserver/geoserver/pull/4

–
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.