Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-devel] initial contribution - git branch

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

Back to the top