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
