[Incubator] gvSIG incubation push

Tue Oct 7 09:00:58 PDT 2014

I understand, I am not sure we want to soften our stance on reviewing code
(we have already softened things by asking for only a review rather than a
fix). Do you think a regex search (or an automated tool) could help you cut
down the files that need attention? Only other thing I could say is to open
a bug ticket for each of the four projects - indicating that the status is
unknown.

Deepening on how your team functions it may be easier to get a volunteer to
fix an "out standing issue" then to volunteer for incubation :)  Actually
with your great gvSig partner program you may be able to ask a community
member or organisation who does not normally program to help out.
--
Jody

Jody Garnett

On Thu, Oct 2, 2014 at 6:08 AM, Manuel Madrid <mmadrid at gvsig.com> wrote:

>  Hi Jody,
>
> Thank you very much for taking a look at our provenance review and for
> this detailed description.
>
> Within the 3% of the code that still has not been reviewed we could find
> basically two cases:
> 1) Files copied from other projects (like your third point).
> 2) Portions of code copied from other projects.
>
> In general we can assume that, in the first case, we kept the original
> headers and, in the second case, we included in our header a mention saying
> that it includes portions of code from the original project. We are pretty
> sure that this is Ok in at least three of the four not reviewed projects.
> The problem is that we cannot guarantee that without reviewing all the
> files.
>
> Best,
> Manuel.
>
>
> On 01/10/14 19:08, Jody Garnett wrote:
>
> We all understand the release cycle :) And really hope you are close.
> Reading your email I am not sure I understand the difference between core
> source code that has been reviewed and the 3% remaining external code?
>
>  I have experience of three similar things - perhaps you could tell me
> which one you mean?
>
>  1) pending code: GeoServer maintains a "community" folder in our source
> code for experiments and new developers. We do not build this source code
> into our binary and it has not had its license and headers reviewed. When a
> module is "ready" a member of the GeoServer team will review and add it
> into the main codebase - but really it is a play area for developer out
> reach. The source code is available for download - but has not been checked
> by the GeoServer team (and is not being compiled and distributed by the
> GeoServer team).
>
>  So if your 3% is like this - no worries. Explain in your provenance
> review that this 3% is a work in progress and will be checked before being
> distributed.
>
>  2) External dependency: GeoTools uses the Apache Commons library - we
> checked that the apache license worked with LGPL for incubation, but we did
> not download the apache commons library source code and check each file.
> The GeoTools team trusts the apache foundation to sort that out, if they
> make a mistake we may need to do something about it but we will deal with
> it when the time comes.
>
>  So if your 3% is like this you are doing too much work - only check what
> your team manages. If you build it check it, if you get it from maven
> central check the license works out (as you do not want to annoy another
> team).
>
>  3) Copying a file from another project. GeoTools has several files that
> have been copied from Apache - and needed to ensure they had the original
> Apache License header on top of them. This is why when you look at our license
> page <http://docs.geotools.org/latest/userguide/welcome/license.html> you
> can see a note about the library being LGPL ... along with a few other
> files that have been provided to us.
>
>  Reading your provenance-review
> <http://www.gvsig.org/plone/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2-1-0/provenance-review> -
> I think this is what you mean. There was no need to seperate out into an
> external project (as long as the license is compatible). Just leave the
> origional headers as is. Depending on the license terms you may need to
> make a note in your user docs - as was done in the GeoTools license page.
>
>  If you need to modify the files a bit after making a copy (say to patch
> an issue) you can get an interesting header example - as shown in "Example
> from Tutorial or Magazine Code" from GeoServer
> <https://github.com/geoserver/geoserver/wiki/Expectations-and-Examples>.
>
>      /*
>      * Copyright (c) 2007 - 2013 OpenPlans - www.openplans.org. All
> rights reserved.
>      * Copyright 2003 Jayson Falkner (jayson at jspinsider.com)
>
>       * This code is from "Servlets and JavaServer pages; the J2EE Web
> Tier",
>      * http://www.jspbook.com. You may freely use the code both
> commercially
>      * and non-commercially. If you like the code, please pick up a copy of
>      * the book and help support the authors, development of more free
> code,
>      * and the JSP/Servlet/J2EE community.
>      *
>      * Modified by David Winslow <dwinslow at openplans.org> on 2007-12-13.
>      */
>
>  So if your 3% is like this don't worry, leave the original headers alone
> and you are good to go.
>
>  Jody Garnett
>
> On Wed, Oct 1, 2014 at 3:25 AM, Manuel Madrid <mmadrid at gvsig.com> wrote:
>
>> Hi Dimitris,
>>
>> Good to hear from you again and thank you very much for being willing to
>> help us again. We are really almost done. Let me give you a general view of
>> the status of the incubation process:
>>
>> We made a big effort some months ago in order to finish the main pending
>> task: the code provenance review. At this moment it has been completely
>> reviewed three core projects which together represent more than 97% of the
>> core source code. Also, within the rest of the core projects (less that 3%
>> of the total code) we reviewed the license compatibility with external
>> libraries so there is only missing the review of external code and file
>> headers of this small part of the code. We identified and fixed all the
>> issues that we detected within the reviewed source code.
>>
>> Regarding the rest of requirements, in principle there are only two
>> missing documents: the release guide and the release testing checklist. We
>> could provide those documents in a short term but, to be honest,
>> unfortunately we are not going to be able to review the provenance of the
>> missing 3% of the code at this moment, as all our resources are completely
>> focused in the final release of gvSIG 2.1. We really hope that this is not
>> a critical issue.
>>
>> You will find all the information related with the gvSIG incubation
>> process in the following links:
>>
>> - Incubation Status:
>> http://wiki.osgeo.org/wiki/GvSIG_Incubation_Status
>> - Incubation Checklist:
>> http://wiki.osgeo.org/wiki/GvSIG_Incubation_Checklist
>> - Provenance review:
>>
>> http://www.gvsig.org/plone/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2-1-0/provenance-review
>>
>> We would very much appreciate if you can review this and let us know if
>> providing the documents I mentioned would be enough to get ready for the
>> graduation.
>>
>> Of course I will be available for talking about this off-list if you want.
>>
>> Best,
>> Manuel.
>>
>>
>> On 01/10/14 09:39, Dimitris Kotzinos wrote:
>>
>>> Hi Manuel and Jeff,
>>>
>>> I was thinking the exact same thing!
>>> It would be great to announce the graduation for the conference.
>>> Manuel, could we try to revive the process? We can talk off-list if you
>>> like!
>>>
>>> Sorry for not pushing too hard and thanks to Jeff for putting this
>>> forward.
>>>
>>> Best regards,
>>>
>>> Dimitris
>>> _______________________________________________
>>> Incubator mailing list
>>> Incubator at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/incubator
>>>
>>
>> _______________________________________________
>> Incubator mailing list
>> Incubator at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/incubator
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/incubator/attachments/20141007/fa67a85e/attachment.html>