Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

Thanks for the input everyone. I put together a proposal with all of the
options put forth on this thread. Apologies if I missed one, if I did just
let me know.


https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy

Like I said before this proposal involves listing out in order of
preference the various options. Feel free to update the proposal or just
reply to this thread and I’ll happily make the update on your behalf.

Thanks!

-Justin

On Tue, Apr 26, 2016 at 2:50 PM Jody Garnett  wrote:

> You asked where I was uncomfortable, not if it made sense :)
>
> --
> Jody Garnett
>
> On 25 April 2016 at 09:37, Justin Deoliveira  wrote:
>
>> I can see how the original date could be useful for cases like this but
>> have you ever seen a situation where something was marked (for example) (c)
>> 2010 and from 2010 to the current date of when you were doing the audit the
>> copyright changed in some meaningful way? I am of course not counting any
>> transfer of copyright to OSGeo, etc… since I would expect that to result in
>> a new copyright timestamp.
>>
>> On Mon, Apr 25, 2016 at 12:12 AM Jody Garnett 
>> wrote:
>>
>>> The part that is making me uneasy is the few times I have done code
>>> audits on this codebase the headers were very useful. While I did have to
>>> duck out to git history on a few occasions it was a rare occurrence - in
>>> part because the team here has done a good job.
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 24 April 2016 at 08:13, Justin Deoliveira  wrote:
>>>
 What is it specifically that is making you uneasy? I thought Ben made a
 pretty strong argument that any dates in the copyright don’t really mean
 anything when it comes to actual legal stuff.

 Doing it periodically via a script does seem like a better compromise…
 although from everything I have heard here I still don’t see why initial
 creation date isn’t enough.

 Once this thread “quiets down” I’ll summarize all of the options that
 folks have put forth and throw them into the proposal and we can vote for
 the options we like best. Since there are a handful of options on the table
 I think perhaps having people rank options 1,2,3 might work best.


 On Sat, Apr 23, 2016 at 7:22 PM Jody Garnett 
 wrote:

> Yeah the longer I think about this one the more I am made
> uncomfortable.  We would be back to "significant" changes needing the
> header updated -
>
> As an alternative wow do you feel about updating the headers once each
> year (via a script) so that individual pull requests are not held up?
>
> --
> Jody Garnett
>
> On 22 April 2016 at 12:05, Justin Deoliveira 
> wrote:
>
>> Cool. I'll write up a quick one.
>>
>> On Fri, Apr 22, 2016 at 1:01 PM Jody Garnett 
>> wrote:
>>
>>> If you would like to make that proposal we can update the developers
>>> guide and get it done ...
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 22 April 2016 at 11:38, Justin Deoliveira 
>>> wrote:
>>>
 Thanks Jody. That helps me understand.

 My thought is that the day to day overhead is not worth being able
 to rest assured that in 75 years GeoTools will still be in good 
 standing
 with regard to copyright ;)

 My vote would be to change to a process where the copyright is set
 to the current year that the file is created or undergoes a major
 overhaul/rewrite. I

 $0.02

 On Fri, Apr 22, 2016 at 12:18 PM Andrea Aime <
 andrea.a...@geo-solutions.it> wrote:

> On Fri, Apr 22, 2016 at 8:06 PM, Jody Garnett <
> jody.garn...@gmail.com> wrote:
>
>> If the PMC wants to make this decision I would be -0, I
>> understand that it would assist with github pull requests, but I 
>> feel we
>> would do so by cutting a corner.
>>
>
> I don't feel strongly either way, copyright updates can be
> automated (see Kevin's GeoServer script), but yeah, it's really 
> annoying to
> require
> every single time a pull request comes in to update the copyright
> headers...
>
> 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
>

Re: [Geotools-devel] Copyright header policy

[Jody Garnett]

You asked where I was uncomfortable, not if it made sense :)

--
Jody Garnett

On 25 April 2016 at 09:37, Justin Deoliveira  wrote:

> I can see how the original date could be useful for cases like this but
> have you ever seen a situation where something was marked (for example) (c)
> 2010 and from 2010 to the current date of when you were doing the audit the
> copyright changed in some meaningful way? I am of course not counting any
> transfer of copyright to OSGeo, etc… since I would expect that to result in
> a new copyright timestamp.
>
> On Mon, Apr 25, 2016 at 12:12 AM Jody Garnett 
> wrote:
>
>> The part that is making me uneasy is the few times I have done code
>> audits on this codebase the headers were very useful. While I did have to
>> duck out to git history on a few occasions it was a rare occurrence - in
>> part because the team here has done a good job.
>>
>> --
>> Jody Garnett
>>
>> On 24 April 2016 at 08:13, Justin Deoliveira  wrote:
>>
>>> What is it specifically that is making you uneasy? I thought Ben made a
>>> pretty strong argument that any dates in the copyright don’t really mean
>>> anything when it comes to actual legal stuff.
>>>
>>> Doing it periodically via a script does seem like a better compromise…
>>> although from everything I have heard here I still don’t see why initial
>>> creation date isn’t enough.
>>>
>>> Once this thread “quiets down” I’ll summarize all of the options that
>>> folks have put forth and throw them into the proposal and we can vote for
>>> the options we like best. Since there are a handful of options on the table
>>> I think perhaps having people rank options 1,2,3 might work best.
>>>
>>>
>>> On Sat, Apr 23, 2016 at 7:22 PM Jody Garnett 
>>> wrote:
>>>
 Yeah the longer I think about this one the more I am made
 uncomfortable.  We would be back to "significant" changes needing the
 header updated -

 As an alternative wow do you feel about updating the headers once each
 year (via a script) so that individual pull requests are not held up?

 --
 Jody Garnett

 On 22 April 2016 at 12:05, Justin Deoliveira 
 wrote:

> Cool. I'll write up a quick one.
>
> On Fri, Apr 22, 2016 at 1:01 PM Jody Garnett 
> wrote:
>
>> If you would like to make that proposal we can update the developers
>> guide and get it done ...
>>
>> --
>> Jody Garnett
>>
>> On 22 April 2016 at 11:38, Justin Deoliveira 
>> wrote:
>>
>>> Thanks Jody. That helps me understand.
>>>
>>> My thought is that the day to day overhead is not worth being able
>>> to rest assured that in 75 years GeoTools will still be in good standing
>>> with regard to copyright ;)
>>>
>>> My vote would be to change to a process where the copyright is set
>>> to the current year that the file is created or undergoes a major
>>> overhaul/rewrite. I
>>>
>>> $0.02
>>>
>>> On Fri, Apr 22, 2016 at 12:18 PM Andrea Aime <
>>> andrea.a...@geo-solutions.it> wrote:
>>>
 On Fri, Apr 22, 2016 at 8:06 PM, Jody Garnett <
 jody.garn...@gmail.com> wrote:

> If the PMC wants to make this decision I would be -0, I understand
> that it would assist with github pull requests, but I feel we would 
> do so
> by cutting a corner.
>

 I don't feel strongly either way, copyright updates can be
 automated (see Kevin's GeoServer script), but yeah, it's really 
 annoying to
 require
 every single time a pull request comes in to update the copyright
 headers...

 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, 

Re: [Geotools-devel] wfs-ng vs wfs datastore fight!

[Andrea Aime]

Thanks Niels,
Mark, I believe this opens the road for you to re-open that ticket (or
create a new one) and
possibly present a pull request to create an upgrade path for yourself (and
everybody
else using the wfs store directly).

Cheers
Andrea


On Sat, Apr 23, 2016 at 12:18 AM, Niels Charlier  wrote:

> Andre,
>
> The reason I closed it as "not a bug" was because I knew it was done by
> intentional design (not by me, but by the initial developer of wfs-ng) for
> a particular purpose and therefore I did not consider it a bug. You do make
> good points to criticise this choice, which does affect backwards
> compatibility. I do not personally oppose your alternative suggestion.
>
> Regards
> Niels
>
>
> On 04/22/2016 07:48 PM, Andrea Aime wrote:
>
> On Thu, Apr 21, 2016 at 7:52 PM, Jody Garnett 
> wrote:
>
>>
>> > Hum... wfs-ng was supposed to be a drop-in replacement, not having a
 upgrade
 > path seems to be a serious issue to me.
 > Where is it documented?

 Quick search got us this:
 https://osgeo-org.atlassian.net/browse/GEOT-4883
 and we googled some more messages on it.
>>>
>>> A backwards incompable change blocking upgrades presented as a GeoServer
>>> requirement and resolved as "not a bug"...
>>>
>>
>> Reading this issue, and I agree it is not a bug - the new datastore is
>> behaving as designed in order to preserve valid names for GML generation.
>>
>
> Jody I believe we have a problem here, in terms of responsibilities. Is it
> really the job of the stores to decide what is valid, and what is not?
> Not all usage is WFS cascading, stores are used for a number of other
> cases, which might have different naming limitations.
>
> Also from a consistency point of view, did you know that you can create a
> typename like "a:b" using a postgis store?
>
> > create table "a:b" (id serial, geom geometry(POLYGON, 4326));
> CREATE TABLE
>
> And then the datastore is happily returning a:b as the typename,
> And of course we also have shapefiles, on linux a file name like a:b.shp
> is also completely valid.
>
> With you and Niels claiming that is not a bug, we have a difficult
> situation, as nobody else can just jump in and make
> the upgrade path easier, since according to your evaluation, we'd be
> introducing a bug... (and from that same point of view,
> then jdbc store and shapefile store are buggy too...).
>
> Unless of course your position is a bit more relaxed, as in, you don't
> consider that a bug, but the behavior returning the native
> name is valid too.
>
>
>>
>> For this specific case the old datastore would of required a similar fix
>> (to prevent type names being of the form
>> "local_namespace:remote_namespace:typename").
>>
>>
>>> As far as I know GeoServer was already handling the ":" in the name, and
>>> the admin is able to rename layers as they see fit.
>>> Yep, there is code stripping the prefix:
>>>
>>> https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/catalog/CatalogBuilder.java#L1212
>>>
>>
>> GeoServer may have work arounds, but I do not mind if the new DataStore
>> is taking more care to produce consistent type names.
>>
>
> See Mark's situation though. I'm also aware of other situations like this
> one that will be broken by an upgrade (systems configured
> to work against well known type names in remote servers).
>
> Mind, I checked, GeoServer is not affected, because internally we have
> this little thing that hides from GeoServer the columns and
> guess what, replaces them with underscores. See here:
>
>
> https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/vfny/geoserver/util/DataStoreUtils.java#L74
>
> and then the retyper does this:
>
>
> https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/feature/retype/RetypingDataStore.java#L252
>
> So luckily for GeoServer even if the store did change its behavior,
> nothing changed config wise (we end up seeing a_b as the native
> type name regardless of whether the store returns a:b or a_b because of
> the above wrapper).
>
> Given this, I'd still make it possible for GeoTools users to upgrade from
> wfs to wfs-ng without this much hassle by exposing the
> actual native type name.
> If the worry is about valid type names for GML, I'm more than happy to
> contribute a little utility wrapping store based on the GeoServer one
> that does the same thing as RetypingDataStore, but centralized in one
> place, and optional, only for those that actually need to do GML encoding.
> A DataUtilities.makeGmlCompatible(DataStore) -> DataStore of sorts.
>
> 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
>