Ahh Ok I get what you're saying. Fair enough.
Jesse
On 5-May-06, at 12:25 PM, Justin Deoliveira wrote:
Yes, that is what I am talking about doing. Sorry, I think I got
confused , that happens quite easily :). So yes, in this proposed
strategy if you are making sure that bug fixes / improvements are
making it onto trunk now, they will get onto fm just fine. THe
trick is improvments that you make after the particular module has
been copied to fm. For instance it may take a coupel of weeks to
port postgis for instance. Which is why I think we need jira to
help manage what we need to merge after the fact. Does that make
any sense?
-Justin
Jesse Eichar wrote:
Can't you merge changes from trunk to the FM branch? or does
that cause too many conflicts?
Jesse
On 5-May-06, at 12:11 PM, Justin Deoliveira wrote:
It depends on what our transition strategy to fm is going to be.
Since much of trunk as it stands today wont make it onto fm
(pretty much all of main and api) I think it makes more sense to
merge trunk onto fm as opposed to merging fm onto trunk. If we
go the other way we have to fix all conflicts at once which wont
be fun.
And then once fm is all ready to go we can make it the new trunk
or switch them up or whatever.
If anyone else has any ideas for a different transition strategy
I am all ears.
-Justin
Jesse Eichar wrote:
Hey Justin,
All my changes have been put on both trunk and 2.2.x so as long
as you are merging onto trunk you will get all my changes.
Jesse
On 5-May-06, at 1:22 AM, Justin Deoliveira wrote:
Hi folks,
As we all know FM has been out on a branch for quite some time
now. Checking the subversion history it was pulled over on
Mar 1st. My worry is that we are going to miss out on a lot
of bug fixes in the datastore modules (like the work dave has
done on postgis recentley, and jesse's continued improvements
to shapefile).
So, I am not sure if something like this is already in the
works, but I would like to propose the following strategy for
porting modules to FM:
1. Sync up module between 2.2.x and trunk
2. Copy module from trunk to FM
3. Create JIRA task so we can catch any bug fixes that occur
on 2.2.x / trunk after this point
4. Port module to new feature model on FM
5. Merge any outstanding bug fixed to FM
If this sounds reasonable to people I can write this up go
through and create a jira task for the entire process, with
sub tasks for each module. Do we have a single place to whip
up docs for FM? I see a bunch of stuff under http://
docs.codehaus.org/ display/ GEOTOOLS/2.3.x
-Justin
--
Justin Deoliveira
[EMAIL PROTECTED]
The Open Planning Project
http://topp.openplans.org
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web
services, security?
Get stuff done quickly with pre-integrated technology to make
your job easier
Download IBM WebSphere Application Server v.1.0.1 based on
Apache Geronimo
http://sel.as-us.falkag.net/sel?
cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Justin Deoliveira
The Open Planning Project
[EMAIL PROTECTED]
--
Justin Deoliveira
The Open Planning Project
[EMAIL PROTECTED]
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
