> This I admit is true ;) , actually I just created a branch : locationtech_ip
> (based on the 1.4.0 release tag)
>
>
>
>
>
Okay I can see your branch here:
- https://github.com/uDig/udig-platform/tree/locationtech_ip
> We can start working to fix CQ issues and push these changes to this branch.
> Whenever we feel comfortable with this changes we can create a tag for this
> and provide an other zip file for IP Team. Let's tag these steps with a
> prefix like locationtech_ip or something shorter..
>
>
>
I asked Sharon if she was interested in the idea, I think she is ready for the
triage step.
I don't want to present her a moving target.
> > I will be in position to move on this from Friday onward - does that
> > qualify as "quickly"?
> >
> > We can keep discussion no this email list, and we will have to take your
> > guidance on how to communicate with the IP team. Should we advise them on
> > this idea of issuing a second "cut down" archive with their initial issues
> > resolved?
>
> 1+ Its kind of flip-flopping between IPZilla and different mailing lists.
> Actually I thought about creating tickets in JIRA as tasks. Jody are you in
> the position to create an other component in JIRA to organize these tasks?
> Otherwise we can use the confluence wiki (e.g.
> http://udig.refractions.net/confluence/display/UDIG/Eclipse+Foundation+LocationTech)
I had updated that page as complete, since we are now part of LocationTech.
I was taking notes on infrastructure migration, including code migration here:
- http://locationtech.org/wiki/index.php/UDig_Infrastructure_Migration#Code
That said I like your idea of a component or tag for IPZilla issues.
> Jody, I thing we should separate IP issues from feature updates. IMHO its
> hazardous changing core functionality during infrastructure changes. Nobody
> can track these afterwards and its will be a pain to get back a running
> system/release although I thing your patch looks good.
>
>
>
I was not considering this a feature update, just trying to lockdown a stable
(rather than milestone release of GeoTools). However I am prepared to say I
missed the boat on this one…
I trust it is easier for the IP team to review a new version of a jar they have
previously approved.
> But what about changing geotools dependencies after IP Team reviewed codebase
> and accepted the contribution? Do we need an other IP run afterwards?
>
>
>
Best ask Wayne for the details, my understanding is we need to issue an IP
request (there is a button the developer portal) for each jar+version used.
Jody
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
