[Geoserver-devel] GeoServer 2.12-RC1 Release retrospective

Hello All,

This latest release has been fraught with peril (as is usual for RC1 releases). Now that it is complete, there are a few things I wanted to bring up:

Migration to build.geoserver.org

Over the past few months, we have been gradually migrating to build.geoserver.org as our new build server. As of now, I believe the only remaining builds not fully migrated are the cite tests.

  • When constructing the 2.12 jobs for the new stable branch, I have only added them to build.geoserver.org. Unlike most of the other jobs on there, I have set them up to notify the mailing lists if they fail. Now that build.geoserver.org is more stable, we should consider swapping other notifications from ares to build.geoserver.org.
  • When updating the GeoServer download page (geoserver.github.io), I have updated all nightly builds to point to build.geoserver.org instead of ares. Both new and historical builds seem to work.
  • When updating the doc links on docs.geoserver.org, I attempted to change the nightly builds to link to build.geoserver.org instead of ares. I was unsuccessful, as build.geoserver.org only supports https, and docs.geoserver.org only supports http. I have added a 2.12 nightly doc build to ares for now. A long-term solution may involve migrating docs.geoserver.org, perhaps to a github pages site.
    SourceForge outage

The SourceForge outage midweek caused a delay in the release, along with other chaos, like temporarily knocking out the mailing lists.

  • We should revisit using SourceForge to host artifacts. GitHub supports attaching artifacts to releases; besides the time required to set this up, does anyone know of any compelling reasons not to use this feature for GeoTools, GeoWebCache and GeoServer releases? It seems fairly easy to use.

Doc updates

When going through the release procedures, I found a few issues, and have updated them accordingly. PRs available for review:

Windows and Mac build

  • The windows build on build.geoserver.org is now fully automatic, and integrated with the regular release procedure.
  • The mac build still requires some manual steps from someone with access to the Boundless desktop-ci jenkins build box.

Torben

On Mon, Oct 2, 2017 at 8:09 PM, Torben Barsballe <
tbarsballe@anonymised.com> wrote:

Hello All,

This latest release has been fraught with peril (as is usual for RC1
releases). Now that it is complete, there are a few things I wanted to
bring up:

*Migration to build.geoserver.org <http://build.geoserver.org>*

Over the past few months, we have been gradually migrating to
build.geoserver.org as our new build server. As of now, I believe the
only remaining builds not fully migrated are the cite tests.

   - When constructing the 2.12 jobs for the new stable branch, I have
   only added them to build.geoserver.org. Unlike most of the other jobs
   on there, I have set them up to notify the mailing lists if they fail. Now
   that build.geoserver.org is more stable, we should consider swapping
   other notifications from ares to build.geoserver.org.

Agreed

   - When updating the GeoServer download page (geoserver.github.io), I
   have updated all nightly builds to point to build.geoserver.org
   instead of ares. Both new and historical builds seem to work.

Oooh, look at that, nice: https://build.geoserver.org/geoserver/ and
https://build.geoserver.org/geowebcache/
I was checking geotools too, it seems like the nightly builds for it are
not there yet: https://build.geoserver.org/geotools/
In any case, much appreciated :slight_smile:

   - When updating the doc links on docs.geoserver.org, I attempted to
   change the nightly builds to link to build.geoserver.org instead of
   ares. I was unsuccessful, as build.geoserver.org only supports https,
   and docs.geoserver.org only supports http. I have added a 2.12 nightly
   doc build to ares for now. A long-term solution may involve migrating
   docs.geoserver.org, perhaps to a github pages site.

Seems like a good suggestion

*SourceForge outage*

The SourceForge outage midweek caused a delay in the release, along with
other chaos, like temporarily knocking out the mailing lists.

   - We should revisit using SourceForge to host artifacts. GitHub
   supports attaching artifacts to releases; besides the time required to set
   this up, does anyone know of any compelling reasons not to use this feature
   for GeoTools, GeoWebCache and GeoServer releases? It seems fairly easy to
   use.

Same worries I voiced earlier:

   - We pump out a lot of releases, will github complain that we are using
   too much space? Is there any way to check
   - Should we transfer the full history, or just part?

I was also worried about world-wide download performance, but last I
checked at least from Italy downloading a large
binary from Github was fast.
I tried with the GeoTools 18-RC1 artifacts, available on github, it used
all of my (limited) bandwidth.
Maybe others want to try as well? Would be interesting to get some info
from Australia/New Zealand, Asia, Africa:

https://github.com/geotools/geotools/releases/tag/18-RC1

*Windows and Mac build*

   - The windows build on build.geoserver.org is now fully automatic, and
   integrated with the regular release procedure.

Awesome

   - The mac build still requires some manual steps from someone with
   access to the Boundless desktop-ci jenkins build box.

I guess we know who to bother when doing releases then :slight_smile:

Cheers
Andrea

==
GeoServer Professional Services from the experts! Visit http://goo.gl/it488V
for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

Oooh, look at that, nice: Index of /geoserver/ and
Index of /geowebcache/
I was checking geotools too, it seems like the nightly builds for it are
not there yet: Index of /geotools/
In any case, much appreciated :slight_smile:

Does geotools actually produce artifacts from its nightly builds? Looking
at ares, it appears the same as build.geoserver.org:
http://ares.boundlessgeo.com/geotools/

*SourceForge outage*

The SourceForge outage midweek caused a delay in the release, along with
other chaos, like temporarily knocking out the mailing lists.

   - We should revisit using SourceForge to host artifacts. GitHub
   supports attaching artifacts to releases; besides the time required to set
   this up, does anyone know of any compelling reasons not to use this feature
   for GeoTools, GeoWebCache and GeoServer releases? It seems fairly easy to
   use.

Same worries I voiced earlier:

   - We pump out a lot of releases, will github complain that we are
   using too much space? Is there any way to check
   - Should we transfer the full history, or just part?

I was also worried about world-wide download performance, but last I
checked at least from Italy downloading a large
binary from Github was fast.
I tried with the GeoTools 18-RC1 artifacts, available on github, it used
all of my (limited) bandwidth.
Maybe others want to try as well? Would be interesting to get some info
from Australia/New Zealand, Asia, Africa:

Release GeoTools 18-RC1 · geotools/geotools · GitHub

Definitely seems like something that needs more analysis and discussion.
Size-wise, we should be fine - it doesn't look like github imposes much in
the way of limits
<https://help.github.com/articles/distributing-large-binaries/&gt; for release
artifacts. Would certainly like to hear from people in other regions about
bandwidth usage.

As for transferring the history, good question. How about this for a
suggestion: Don't transfer over any history, and use SourceForge as a
source for historical artifacts. For a year or so, release artifacts to
both SourceForge and GitHub, linking to GitHub in the blog post. After
that, fully move to GitHub and stop releasing to SourceForge (At this
point, we should have a full set of Maintenance and Stable artifacts in
GitHub). This also gives us time to test, and perhaps re-consider our
approach.

   - The mac build still requires some manual steps from someone with
   access to the Boundless desktop-ci jenkins build box.

I guess we know who to bother when doing releases then :slight_smile:

Indeed :slight_smile:

Torben

On Tue, Oct 3, 2017 at 6:27 PM, Torben Barsballe <
tbarsballe@anonymised.com> wrote:

Does geotools actually produce artifacts from its nightly builds? Looking
at ares, it appears the same as build.geoserver.org:
http://ares.boundlessgeo.com/geotools/

Doh, you're right, the only artifacts are the snapshot jars, which afaik
are deployed on every build.
Indeed... there is no nightly build for GeoTools, at all :-p

As for transferring the history, good question. How about this for a
suggestion: Don't transfer over any history, and use SourceForge as a
source for historical artifacts. For a year or so, release artifacts to
both SourceForge and GitHub, linking to GitHub in the blog post. After
that, fully move to GitHub and stop releasing to SourceForge (At this
point, we should have a full set of Maintenance and Stable artifacts in
GitHub). This also gives us time to test, and perhaps re-consider our
approach.

Sounds like a good plan. Should be easy to automate (hopefully?)

Cheers
Andrea

==

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V
for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

Today’s meeting brought up sourceforge support for download stats as being useful. GitHub provides a download count, but not the region and operating system specific breakdown.

···

On 2 October 2017 at 11:09, Torben Barsballe <tbarsballe@anonymised.com> wrote:

Hello All,

This latest release has been fraught with peril (as is usual for RC1 releases). Now that it is complete, there are a few things I wanted to bring up:

Migration to build.geoserver.org

Over the past few months, we have been gradually migrating to build.geoserver.org as our new build server. As of now, I believe the only remaining builds not fully migrated are the cite tests.

  • When constructing the 2.12 jobs for the new stable branch, I have only added them to build.geoserver.org. Unlike most of the other jobs on there, I have set them up to notify the mailing lists if they fail. Now that build.geoserver.org is more stable, we should consider swapping other notifications from ares to build.geoserver.org.
  • When updating the GeoServer download page (geoserver.github.io), I have updated all nightly builds to point to build.geoserver.org instead of ares. Both new and historical builds seem to work.
  • When updating the doc links on docs.geoserver.org, I attempted to change the nightly builds to link to build.geoserver.org instead of ares. I was unsuccessful, as build.geoserver.org only supports https, and docs.geoserver.org only supports http. I have added a 2.12 nightly doc build to ares for now. A long-term solution may involve migrating docs.geoserver.org, perhaps to a github pages site.
    SourceForge outage

The SourceForge outage midweek caused a delay in the release, along with other chaos, like temporarily knocking out the mailing lists.

  • We should revisit using SourceForge to host artifacts. GitHub supports attaching artifacts to releases; besides the time required to set this up, does anyone know of any compelling reasons not to use this feature for GeoTools, GeoWebCache and GeoServer releases? It seems fairly easy to use.

Doc updates

When going through the release procedures, I found a few issues, and have updated them accordingly. PRs available for review:

Windows and Mac build

  • The windows build on build.geoserver.org is now fully automatic, and integrated with the regular release procedure.
  • The mac build still requires some manual steps from someone with access to the Boundless desktop-ci jenkins build box.

Torben


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


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


Jody Garnett