Re: [Geoserver-devel] SourceForge exit strategy

[Andrea Aime]

Hi Torben,
I'm tentatively -1 on the idea but willing to discuss.

The proposal you're citing is 2.5 years old and the mailing list trouble we
have had in the past week is
been the only really serious issue we have had since, as far as I remember.

Migrating the lists to OSGeo will generate a very significant disturbance
again, but one of our own making,
we'll probably lose all subscribers* and create two places that people have
to search into before posting a request.

I'd be willing to consider the idea again if we have another SF issue in
the short term, but besides that,
I believe we can tolerate one trouble in 2.5 years, I doubt OSGeo would be
able to significantly
outperform that.

Speaking of which, we keep on having problems with the OSGeo hosted maven
repository,
my colleagues report slowness and occasional inability to connect, I
normally dodge the problem
by building from sources my snapshot and using -nsu in all builds. Now, I
understand we have not
seen similar issues on the mailing list, but it gives the impression SAC is
a bit short handed
(looking at our community, everybody seems to be busy up to their eyeballs
too, so don't think we
can offer help there).

Cheers
Andrea

* even assuming SF will give us the list of subscribers, which they might
not due to privacy,
I don't think we can force subscribe anyone to a new list server hosted by
a different
organization... so we'd likely have to start from scratch


On Tue, Mar 6, 2018 at 10:32 PM, Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:

>
>
>
>
>
>
>
> *SourceForge had outages / reduced service during the week of the GeoTools
> 19-beta / GeoServer 2.13-beta release.This caused: - Delays on mailing list
> discussions and announcements (including the release announcement), - Loss
> of all download statistics for the release, so we don't know how many
> people are downloading / testing it.Once again, this brings up the topic of
> whether we should consider something a bit more reliable than sourceforge
> for hosting mailing lists and release artifacts. There is a preexisting
> migration proposal here:
> https://github.com/geotools/geotools/wiki/SourceForge-exit-strategy
>  One
> suggestion was to start by migrating the GeoTools project (As it is a
> lower-risk migration, given that most people get there artifacts via
> maven), and use that to determine feasibility of migrating the GeoServer
> project.Any thoughts?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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>


-- 

Regards,

Andrea Aime

==
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.

[Geoserver-devel] Build failed in Jenkins: geoserver-2.13.x #19

[monitor]

See 

--
[...truncated 4.37 MB...]
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Application Schema Integration Test
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Importer Core Module
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Web Processing Service Module
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping GeoServer INSPIRE Extensions
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Web Coverage Service 2.0 Earth Observation extensions
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping WCS NetCDF output Module
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Core Monitor Extension
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Security UI JDBC Module
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Security UI LDAP Module
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping GeoServer Security Extension Modules
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Catalog Services for the Web core module
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Importer REST Api Module-ng
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] 

Re: [Geoserver-devel] [Geotools-devel] SourceForge exit strategy

[Jody Garnett]

I like that idea, we would need to coordinate with OSGeo slack with respect
to migrating mailing lists.

--
Jody Garnett

On 6 March 2018 at 13:32, Torben Barsballe 
wrote:

>
>
>
>
>
>
>
> *SourceForge had outages / reduced service during the week of the GeoTools
> 19-beta / GeoServer 2.13-beta release.This caused: - Delays on mailing list
> discussions and announcements (including the release announcement), - Loss
> of all download statistics for the release, so we don't know how many
> people are downloading / testing it.Once again, this brings up the topic of
> whether we should consider something a bit more reliable than sourceforge
> for hosting mailing lists and release artifacts. There is a preexisting
> migration proposal here:
> https://github.com/geotools/geotools/wiki/SourceForge-exit-strategy
>  One
> suggestion was to start by migrating the GeoTools project (As it is a
> lower-risk migration, given that most people get there artifacts via
> maven), and use that to determine feasibility of migrating the GeoServer
> project.Any thoughts?Torben*
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> GeoTools-Devel mailing list
> geotools-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] SourceForge exit strategy

[Torben Barsballe]

*SourceForge had outages / reduced service during the week of the GeoTools
19-beta / GeoServer 2.13-beta release.This caused: - Delays on mailing list
discussions and announcements (including the release announcement), - Loss
of all download statistics for the release, so we don't know how many
people are downloading / testing it.Once again, this brings up the topic of
whether we should consider something a bit more reliable than sourceforge
for hosting mailing lists and release artifacts. There is a preexisting
migration proposal here:
https://github.com/geotools/geotools/wiki/SourceForge-exit-strategy
 One
suggestion was to start by migrating the GeoTools project (As it is a
lower-risk migration, given that most people get there artifacts via
maven), and use that to determine feasibility of migrating the GeoServer
project.Any thoughts?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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] 2.13.0 Release Volunteer

[Torben Barsballe]

We currently do not have a volunteer for the GeoToos 19.0 / GeoWebCache
1.13.0 / GeoServer 2.13.0 release (currently scheduled for March 18th).

Is anyone able to volunteer for this release?

Thanks,
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Suggesting a small change in release procedures: can we cut the stable branch on beta?

[Torben Barsballe]

There was some discussion on this topic in the PMC meeting. Salient points:

   - Should we rename the beta the RC (Basically, the fork/RC would now be
   1 month before the .0 release and there wouldn't be a beta release anymore).
  - The most useful naming scheme for would be whatever people are more
  likely to test
   - Should we still have an RC(2) two weeks before the .0?
  - Only if there are enough bugfixes to warrant it?

Anyone have further opinions on these?

On Thu, Feb 22, 2018 at 11:23 AM, Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:

> PR's for the associated doc changes here:
>
>- https://github.com/geotools/geotools/pull/1811
>- https://github.com/geoserver/geoserver/pull/2763
>
> We also have a release process diagram which includes the freeze. While
> not critical, that could be updated - does anyone have the source files for
> it?
>
> Torben
>
> On Mon, Feb 19, 2018 at 8:14 AM, Torben Barsballe <
> tbarsba...@boundlessgeo.com> wrote:
>
>>
>>
>> On Fri, Feb 16, 2018 at 8:47 AM, Jody Garnett 
>> wrote:
>>
>>> We could also cut the beta just to confirm master is releasable, and not
>>> branch. Make the first release candidate the branch to achieve the same
>>> effect.
>>>
>>> It has the advantage of less moving parts, but we do not get a code
>>> freeze to focus on bugs. But as you point out that is not happening so
>>> much.
>>>
>>
>> Unless I am misunderstanding you, this is what we do currently - branch
>> on the RC. What are you actually suggesting here?
>>
>> Torben
>>
>>
>>
>>> On Fri, Feb 16, 2018 at 2:45 AM Ian Turton  wrote:
>>>
 I agree we hardly ever see any feedback before the .0 release. Which is
 a shame but nothing we do seems to make a difference to customers.

 So +1 for me

 Ian

 On 16 February 2018 at 09:32, Nuno Oliveira <
 nuno.olive...@geo-solutions.it> wrote:

> I don't have any voting power, just want to express my +1 towards that
> change ... and indeed I don't see the advantage of the RC release.
> If users don't provide feedback, bug fix doesn't happen ... what are
> the advantages of having the RC release ?
>
>
> On 02/16/2018 03:18 AM, Ben Caradoc-Davies wrote:
>
>> +1. It does seem that we are not getting much benefit from waiting
>> until RC to branch, and any fix would be applied to master and the new
>> stable before the .0 release. We could drop the RC altogether. The 
>> current
>> procedure incurs not only a delay but also the work of an extra release
>> (the RC).
>>
>> Kind regards,
>> Ben.
>>
>> On 14/02/18 22:58, Andrea Aime wrote:
>>
>>> Hi (apologies for the cross post),
>>> I would like to hear opinions on changing the release procedures
>>> slightly,
>>> and cutting the stable
>>> branch directly on the beta release.
>>>
>>> The reason for not doing the cut on beta but on RC originally was to
>>> push
>>> devs to concentrate
>>> on bug fixing.
>>> However, since then we have shortened the beta life to just two
>>> weeks, we
>>> are not getting significant
>>> feedback from users (which typically starts flowing in on .0 or even
>>> .1
>>> releases), and the bug fixing activity
>>> is rather small (I try to do it anyways, but find myself fixing old
>>> bugs,
>>> not new ones).
>>>
>>> I've also noticed that I routinely created short lived forks of
>>> master to
>>> keep on working on my daily job.
>>> Wondering, am I the only one?
>>>
>>> If not, or if others don't mind anyways, wouldn't it be better to
>>> just cut
>>> the stable branch on beta instead?
>>>
>>> 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
>>> 

[Geoserver-devel] GeoTools / GeoServer Meeting 2018-03-06

[Torben Barsballe]

*Attending:Torben BarsballeKevin SmithBrad HardsJody GarnettAgenda - Change
in release procedures- Release train- Sourceforge issues (and
alternatives)Previous Meetings Actions: - Java Jigsaw Compatibility - Take
this to a technical debt page, it is not acting like a proposal -
TODOActions: - Torben: Java Jigsaw Compatibility - Take this to a technical
debt page, it is not acting like a proposal- Make GSIP for forking on Beta
instead of RC. - All: Further mailing list discussion- Add note on security
fix procedures to release docs- Jody/Kevin/Torben: 2.13-RC release- Torben:
Ask for 2.13.0 release volunteers on mailing list- Jody: Proposal for
jsr-275 units library upgrade- Torben: Start mailing list discussion for
SourceForge exit strategyMeeting notesJody asked about release schedule. We
have the Beta out
(http://blog.geoserver.org/2018/02/22/geoserver-2-13-beta-released/
).Change
in release proceduresWe should write down how to gradually announce
security fixes in our release announcements. - Mention when a release
includes an initial security fix- When fix is available in stable and
maintenance we can fill in details (editing prior blog post)- Action: Add
this to release docsFork on Beta instead of RCMailing list thread:
https://sourceforge.net/p/geoserver/mailman/geoserver-devel/thread/CA%2BnxMTuJT-eN1L0ZCgQ0kv34oY2YY7AntBfXJD-9%3Dw%3D8O6Kyeg%40mail.gmail.com/#msg36227253
PRs:
- https://github.com/geotools/geotools/pull/1811
-
https://github.com/geoserver/geoserver/pull/2763
Action: GSIP
PendingDiscussion - If we fork a new branch at this point we may as well
just call it a release candidate.- Q: What is more likely to get people to
test it - "beta" or "RC"? Action: Discuss on mailing list- Going straight
to release candidate is kind of warranted, our code is pretty stable at
this point.- Do we still want to have a release after two weeks (what was
previously the RC)? … If there are enough bugfixes to make it worthwhile.
Action: Add this to the above PRs- Do we want to branch a month in advance
- Yes, this puts a firm deadline on new features, while still giving time
to fix any bugs introduced by said new features- This change also means we
“give up” having a code freeze (forcing developers to down tools and focus
on release issues).- Should make sure to include a bug stomp in the “code
freeze”? Actually it works out this way - release is on the 18th, bug stomp
is last Friday of the monthRelease Train2.13-beta was released on February
20/21, and we branched of of master at that time.2.13-RC1 should be going
out this week - volunteers: Jody (GeoTools), Kevin (GeoWebCache), Torben
(GeoServer).See above for discussion on whether the 2-week release is still
necessary (conclusion: only if there are sufficient bugfixes)2.13.0 release
- need volunteers. Action: Ask on mailing list.FOSS4G-NADates: 14-16 May,
17th for workshops / community dayTalks accepted:  State of GeoServer,
State of GeoWebCache,  Need to develop slide decks. Should include recent
changes and roadmap of planned changes.  Please let us know if there’s
anything you want to highlight.Possibly some Java 9 migration work on the
community day, around developers’ workshop attendance as
applicable.SourceForge IssuesSourceForge had outages / reduced service
during the week of the 2.13-beta release.This caused: - Delays on mailing
list discussions and announcements (including the release announcement), -
Loss of all download statistics for the release, so we don't know how many
people are downloading / testing it.Once again, this brings up the topic of
whether we should consider something a bit more reliable than sourceforge
for hosting mailing lists and release artifacts: - Mailing lists - OSGeo
hosted list?- Release artifacts: GitHub- Can access minimal download
statistics via:
http://www.somsubhra.com/github-release-stats/?username=GeoWebCache=geowebcache

- so there is at least an API endpoint.- No OS breakdown- GeoTools Proposal
(2015): https://github.com/geotools/geotools/wiki/SourceForge-exit-strategy
 -
Action: Start mailing list discussion, starting with GeoTools
(low-risk)Sprint Planning - OGC WFS 3.0: Andrea is attending remotely this
week, asked for a community module- OSGeo Bonn: Jody is attending, may look
at replacing our pre-jsr-275 units library- Concerned this will prevent us
running on Java 10 even with all the “jigsaw” workarounds- Can look at
GeoToolkit which has already migrated to new units library replacement-
Action: A proposal will be needed to write down the 

[Geoserver-devel] NetCDF Data Packing Formula

[Mrc0113]

Hi, 


I am using geoserver v2.12.2 with the JVM system property to have geoserver
unpack NetCDF data with respect to the scale_factor/add_offset attributes: 
-Dorg.geotools.coverage.io.netcdf.enhance.ScaleMissing=true 
Geoserver seems to be doing the unpacking fine, but when I configure my
coverage.xml to re-pack the data into a smaller datatype (such as byte) the
formula used treats the datatype as unsigned and when the NetCDF file is
read by external software the values are interpreted incorrectly since
NetCDF convention defines the packed data types (Byte, Short, Int) as signed
integers.  Given this convention, I am curious if there is a reason this
algorithm was selected that I'm overlooking or if this is a bug in the
software.  I would recommend that the formula be updated to use the "signed"
one below until "ubyte, ushort, and uint" data types are supported by
geoserver for packing.

For reference, the formulas are defined in DataPacking.java 
https://github.com/geoserver/geoserver/blob/master/src/extension/netcdf-out/src/main/java/org/geoserver/web/netcdf/DataPacking.java

There is more information at the link below, but these seem to be the two
recommended options for data packing while reserving space for missing data.
The first is for signed packed values and the second is for unsigned packed
values which is the one that geoserver is using.  
https://www.unidata.ucar.edu/software/netcdf/docs/BestPractices.html#Packed%20Data%20Values

In either the signed or unsigned case, an alternate formula may be used for
the add_offset and scale_factor packing parameters that reserves a packed
value for a special value, such as an indicator of missing data. For
example, to reserve the minimum packed value (-2^n\ -\ 1^) for use as a
special value in the case of signed packed values:

> scale_factor =(dataMax - dataMin) / (2^n^ - 2)

> add_offset = (dataMax + dataMin) / 2

If the packed values are unsigned, then the analogous formula that reserves
0 as the packed form of a special value would be:

> scale_factor =(dataMax - dataMin) / (2^n^ - 2)

> add_offset = dataMin - scale_factor


Thanks for any help or information I might be overlooking! 
- Mrc0113



--
Sent from: http://osgeo-org.1560.x6.nabble.com/GeoServer-Dev-f3819232.html

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Reminder: GeoTools / GeoServer meeting at 19:30 UTC on Tuesday

[Ben Caradoc-Davies]

Apologies: I might not attend this meeting.

On 06/03/18 09:51, Ben Caradoc-Davies wrote:

GeoTools / GeoServer committee meeting on Skype at 19:30 UTC on Tuesday:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=GeoTools+/+GeoServer+Meeting=2018=3=6=19=30=0=1 


--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel