>
> 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 :)
>
>
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:
>
> https://github.com/geotools/geotools/releases/tag/18-RC1
>
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/> 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 :-)
>
Indeed :)
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
