[fdo-internals] RE: Random question

[Chris Erickson]

Should I submit my arcsde fix to the sandbox then for testing?


chris erickson
developer
chris at cartopac.com
970.493.9500 x 191
970.482.1485 (fax)



-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Friday, March 06, 2009 12:09 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question

Please submit all your existing sandbox code submitted by Monday. At that point I will move the existing sandbox code into sandbox/3.4.0.

Greg

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Friday, March 06, 2009 1:37 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question

I also like the idea of have per-feature or per-release sandboxes rather than per-user sandboxes

ie:

sandbox/3.4.0
sandbox/3.4.0_ArcSDE93
sandbox/3.3.2_Performance

Greg

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Friday, March 06, 2009 1:26 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question

Typically in this case, the developer would sandbox the latest version (let's say 3.4) and the port the changes back to 3.3. I can say that right now because the code streams for 3.3 and 3.4 are very similar. However, I have not given much thought to the whole idea of sandboxing a previous development stream. Usually such changes as that are done in a sandbox in preparation of being submitted into the trunk. I can see how use can you describe can be useful, but don't think it will be a large part of whatever sandboxing occurs. 

In any case, if developers want their own sandbox, I won't stand in the way. It would be easy to move the current sandbox into a subfolder.


Greg

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Friday, March 06, 2009 1:19 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question

Right...

But what if someone wanted to make some relatively intrusive changes to
a provider against two different branches of FDO (say, 3.4 and 3.3) to
fix a particular defect or performance problem?

Jason

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: March-06-09 10:09 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question

I think that the only item the current setup would not support is #2,
the issue of isolation. But since we are provider driven, is there a
chance we will have multiple people sandboxing the same provider? I like
the idea of a common sandbox as it allows you to immediately determine
if the changes others are working on will work with the changes you are
making without breaking the build in the trunk, etc. Sandbox changes to
FDO itself can immediately be seen and their worth be assessed by all
provider developers. 

However, this is my philosophy. If you really need a sandbox for your
own development, we could set something up.
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals