OSGeo.org › OSGeo Software and Data Projects › Feature Data Objects (FDO) › FDO Internals

RE: [fdo-users] Trying to Deploy FDO to Web

10 messages

RE: [fdo-users] Trying to Deploy FDO to Web

Reply Threaded

Why don't you log a Trac defect and attach a svn patch of the changes you made. If you want this change to go into the 3.4.0 release, you should make a motion on the fdo-internals site and ask for feedback from the PSC. At this point only stop-ship issues should be nominated for resolution.

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Chris Erickson
Sent: Monday, March 02, 2009 2:40 PM
To: FDO Users Mail List
Subject: RE: [fdo-users] Trying to Deploy FDO to Web

Greg,
The delay load issue is between the managed and unmanaged code.

If in the various managed core dlls (OsGeo.FDO, OSGeo.FDO.Common, OSGeo.FDO.Geometry, OSGeo.FDO.Spatial) the unmanaged dlls are set to delay load, then the application can start and modify its path before the unmanaged core dlls are loaded.

This is necessary for any web applications that don't want to have to install the unmanaged FDO dlls on the system path, which is often not an option.

I've built the managed dlls locally here and set them to delay load their unmanaged dependencies, and I'm able to use FDO in web-apps by setting the environment path in the Global.asax (ASP.NET).

chris erickson
developer
[hidden email]
970.493.9500 x 191
970.482.1485 (fax)

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Greg Boone
Sent: Monday, March 02, 2009 9:21 AM
To: FDO Users Mail List
Subject: RE: [fdo-users] Trying to Deploy FDO to Web

I do not have a list of FDO DLLs that are meant to be delay loaded. Typically, for the FDO core side of things, no core FDO DLL's are delay loaded within the implementation of FDO itself. As for the FDO providers, I believe they are not loaded until requested through the FDO Client Services API, at which time the DLL identified in providers.xml is loaded along with all its dependencies.

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Chris Erickson
Sent: Tuesday, February 24, 2009 12:15 PM
To: FDO Users Mail List
Subject: RE: [fdo-users] Trying to Deploy FDO to Web

Greg,
Which dlls are supposed to be delay loaded? The unmanaged FDO dlls are not, which causes issues on web servers (I put in a defect # 463). Is there any chance this will be fixed in 3.4?

chris erickson
developer
[hidden email]
970.493.9500 x 191
970.482.1485 (fax)

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Greg Boone
Sent: Tuesday, February 17, 2009 10:03 AM
To: FDO Users Mail List
Subject: RE: [fdo-users] Trying to Deploy FDO to Web

That DLL should be delay loaded and should not affect FDO from running.

Have you looked at the contents of providers.xml located in the FDO bin directory? Are the paths to the provider files relative or absolute?

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of surrounded
Sent: Tuesday, February 17, 2009 11:46 AM
To: [hidden email]
Subject: RE: [fdo-users] Trying to Deploy FDO to Web

Using DependencyWalker, I see that for OSGeo.FDO.dll and
OSGeo.FDO.Common.dll, DWMAPI.DLL cannot be found.

ANYONE RUN INTO THIS - RECOMMENDATION?

surrounded wrote:

>
> Hi Greg,
>
>
>
> No, so if I download Depends.exe, how would I use it to determine the
> missing module??
>
>
>
> From: Greg Boone (via Nabble)
> [mailto:[hidden email]]
> Sent: Tuesday, February 17, 2009 9:36 AM
> To: Rob Sosnowski
> Subject: RE: [fdo-users] Trying to Deploy FDO to Web
>
>
>
> Have you run depends.exe to try and determine which module cannot be
> found?
>
> -----Original Message-----
> From: fdo-users-bounces@...
> <http://n2.nabble.com/user/SendEmail.jtp?type=node&node=2341773&i=0>
> [mailto:fdo-users-bounces@...
> <http://n2.nabble.com/user/SendEmail.jtp?type=node&node=2341773&i=1> ]
> On Behalf Of surrounded
> Sent: Tuesday, February 17, 2009 11:06 AM
> To: fdo-users@...
> <http://n2.nabble.com/user/SendEmail.jtp?type=node&node=2341773&i=2>
> Subject: [fdo-users] Trying to Deploy FDO to Web
>
>
> Hello,
>
> I'm using FDO within VS 2008 project (web service) and works fine when
> run
> as localhost on my PC.
>
> I've moved the web service to a production server, copied the FDO bin,
> lib,
> and inc folders to the production server, and set the environment PATH
> variable on the server to point to the FDO folders.
>
> When I run the application I get the following error:
> System.IO.FileNotFoundException: The specified module could not be
> found.
> (Exception from HRESULT: 0x8007007E)
>
> ANY IDEAS ON WHAT IS CAUSING THIS? HOW IS FDO SET UP TO RUN ON WEB
> SERVER?
>
> Thanks.....
>
>
> --
> View this message in context:
> http://n2.nabble.com/Trying-to-Deploy-FDO-to-Web-tp2341612p2341612.html
> Sent from the FDO Users mailing list archive at Nabble.com.
>
> _______________________________________________
> fdo-users mailing list
> fdo-users@...
> <http://n2.nabble.com/user/SendEmail.jtp?type=node&node=2341773&i=3>
> http://lists.osgeo.org/mailman/listinfo/fdo-users
> _______________________________________________
> fdo-users mailing list
> fdo-users@...
> <http://n2.nabble.com/user/SendEmail.jtp?type=node&node=2341773&i=4>
> http://lists.osgeo.org/mailman/listinfo/fdo-users
>
>
>
> ________________________________
>
> This email is a reply to your post @
> http://n2.nabble.com/Trying-to-Deploy-FDO-to-Web-tp2341612p2341773.html
> You can reply by email or by visting the link above.
>
>
>
>
>

--
View this message in context: http://n2.nabble.com/Trying-to-Deploy-FDO-to-Web-tp2341612p2341870.html
Sent from the FDO Users mailing list archive at Nabble.com.

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users
_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users
_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users
_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users
_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Chris Erickson-2

RE: [fdo-users] Trying to Deploy FDO to Web

Reply Threaded

Greg,
I did submit something in the trac site (#463), but my svn patch seems to have picked up other project changes related to building on vista x64, so I didn't want to submit a bad patch...

chris erickson
developer
[hidden email]
970.493.9500 x 191
970.482.1485 (fax)

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Greg Boone
Sent: Monday, March 02, 2009 12:45 PM
To: FDO Users Mail List
Cc: FDO Internals Mail List
Subject: [fdo-internals] RE: [fdo-users] Trying to Deploy FDO to Web

Why don't you log a Trac defect and attach a svn patch of the changes you made. If you want this change to go into the 3.4.0 release, you should make a motion on the fdo-internals site and ask for feedback from the PSC. At this point only stop-ship issues should be nominated for resolution.

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Chris Erickson
Sent: Monday, March 02, 2009 2:40 PM
To: FDO Users Mail List
Subject: RE: [fdo-users] Trying to Deploy FDO to Web

Greg,
The delay load issue is between the managed and unmanaged code.

If in the various managed core dlls (OsGeo.FDO, OSGeo.FDO.Common, OSGeo.FDO.Geometry, OSGeo.FDO.Spatial) the unmanaged dlls are set to delay load, then the application can start and modify its path before the unmanaged core dlls are loaded.

This is necessary for any web applications that don't want to have to install the unmanaged FDO dlls on the system path, which is often not an option.

I've built the managed dlls locally here and set them to delay load their unmanaged dependencies, and I'm able to use FDO in web-apps by setting the environment path in the Global.asax (ASP.NET).

chris erickson
developer
[hidden email]
970.493.9500 x 191
970.482.1485 (fax)

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Greg Boone
Sent: Monday, March 02, 2009 9:21 AM
To: FDO Users Mail List
Subject: RE: [fdo-users] Trying to Deploy FDO to Web

I do not have a list of FDO DLLs that are meant to be delay loaded. Typically, for the FDO core side of things, no core FDO DLL's are delay loaded within the implementation of FDO itself. As for the FDO providers, I believe they are not loaded until requested through the FDO Client Services API, at which time the DLL identified in providers.xml is loaded along with all its dependencies.

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Chris Erickson
Sent: Tuesday, February 24, 2009 12:15 PM
To: FDO Users Mail List
Subject: RE: [fdo-users] Trying to Deploy FDO to Web

Greg,
Which dlls are supposed to be delay loaded? The unmanaged FDO dlls are not, which causes issues on web servers (I put in a defect # 463). Is there any chance this will be fixed in 3.4?

chris erickson
developer
[hidden email]
970.493.9500 x 191
970.482.1485 (fax)

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Greg Boone
Sent: Tuesday, February 17, 2009 10:03 AM
To: FDO Users Mail List
Subject: RE: [fdo-users] Trying to Deploy FDO to Web

That DLL should be delay loaded and should not affect FDO from running.

Have you looked at the contents of providers.xml located in the FDO bin directory? Are the paths to the provider files relative or absolute?

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of surrounded
Sent: Tuesday, February 17, 2009 11:46 AM
To: [hidden email]
Subject: RE: [fdo-users] Trying to Deploy FDO to Web

Using DependencyWalker, I see that for OSGeo.FDO.dll and
OSGeo.FDO.Common.dll, DWMAPI.DLL cannot be found.

ANYONE RUN INTO THIS - RECOMMENDATION?

surrounded wrote:

Greg Boone

RE: [fdo-users] Trying to Deploy FDO to Web

Reply Threaded

Attach what you have. I can sort though the changes fairly readily. If I have some questions I will ask.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Chris Erickson
Sent: Monday, March 02, 2009 2:46 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: [fdo-users] Trying to Deploy FDO to Web

Greg,
I did submit something in the trac site (#463), but my svn patch seems to have picked up other project changes related to building on vista x64, so I didn't want to submit a bad patch...

chris erickson
developer
[hidden email]
970.493.9500 x 191
970.482.1485 (fax)

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Greg Boone
Sent: Monday, March 02, 2009 12:45 PM
To: FDO Users Mail List
Cc: FDO Internals Mail List
Subject: [fdo-internals] RE: [fdo-users] Trying to Deploy FDO to Web

Why don't you log a Trac defect and attach a svn patch of the changes you made. If you want this change to go into the 3.4.0 release, you should make a motion on the fdo-internals site and ask for feedback from the PSC. At this point only stop-ship issues should be nominated for resolution.

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Chris Erickson
Sent: Monday, March 02, 2009 2:40 PM
To: FDO Users Mail List
Subject: RE: [fdo-users] Trying to Deploy FDO to Web

Greg,
The delay load issue is between the managed and unmanaged code.

If in the various managed core dlls (OsGeo.FDO, OSGeo.FDO.Common, OSGeo.FDO.Geometry, OSGeo.FDO.Spatial) the unmanaged dlls are set to delay load, then the application can start and modify its path before the unmanaged core dlls are loaded.

This is necessary for any web applications that don't want to have to install the unmanaged FDO dlls on the system path, which is often not an option.

I've built the managed dlls locally here and set them to delay load their unmanaged dependencies, and I'm able to use FDO in web-apps by setting the environment path in the Global.asax (ASP.NET).

chris erickson
developer
[hidden email]
970.493.9500 x 191
970.482.1485 (fax)

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Greg Boone
Sent: Monday, March 02, 2009 9:21 AM
To: FDO Users Mail List
Subject: RE: [fdo-users] Trying to Deploy FDO to Web

I do not have a list of FDO DLLs that are meant to be delay loaded. Typically, for the FDO core side of things, no core FDO DLL's are delay loaded within the implementation of FDO itself. As for the FDO providers, I believe they are not loaded until requested through the FDO Client Services API, at which time the DLL identified in providers.xml is loaded along with all its dependencies.

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Chris Erickson
Sent: Tuesday, February 24, 2009 12:15 PM
To: FDO Users Mail List
Subject: RE: [fdo-users] Trying to Deploy FDO to Web

Greg,
Which dlls are supposed to be delay loaded? The unmanaged FDO dlls are not, which causes issues on web servers (I put in a defect # 463). Is there any chance this will be fixed in 3.4?

chris erickson
developer
[hidden email]
970.493.9500 x 191
970.482.1485 (fax)

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Greg Boone
Sent: Tuesday, February 17, 2009 10:03 AM
To: FDO Users Mail List
Subject: RE: [fdo-users] Trying to Deploy FDO to Web

That DLL should be delay loaded and should not affect FDO from running.

Have you looked at the contents of providers.xml located in the FDO bin directory? Are the paths to the provider files relative or absolute?

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of surrounded
Sent: Tuesday, February 17, 2009 11:46 AM
To: [hidden email]
Subject: RE: [fdo-users] Trying to Deploy FDO to Web

Using DependencyWalker, I see that for OSGeo.FDO.dll and
OSGeo.FDO.Common.dll, DWMAPI.DLL cannot be found.

ANYONE RUN INTO THIS - RECOMMENDATION?

surrounded wrote:

Greg Boone

RE: [fdo-users] Trying to Deploy FDO to Web

Reply Threaded

In reply to this post by Greg Boone

I think all changes at this point, and their proposed solution, should be nominated for inclusion and discussed on the internals site. We have to consider what level of testing would be required to ensure that the proposed changes work as intended. Up until this point we have benefitted from the fact that the Autodesk folks have been QA'ing our builds as a part of their upcoming releases of MapGuide, etc. From my understanding they will not be able to test FDO beyond build G044. Any changes we make will have to be QA'ed by OSGeo members and guarantees made that ensure the change is working as intended and does not break any previous functionality.

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Birch
Sent: Monday, March 02, 2009 3:06 PM
To: FDO Users Mail List
Subject: RE: [fdo-users] Trying to Deploy FDO to Web

Greg,

> At this point only stop-ship issues should be nominated for
resolution.

Does this mean that at this point you would be adverse to the change in
the SQL Server Spatial provider proposed in #469? I feel that this may
be a minor change that could have a large benefit to SQL Server Spatial
users, but don't know enough about whether this would break binary
compatibility.

Jason

_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Jason Birch

Relase process (was Trying to Deploy FDO to Web)

Reply Threaded

Greg,

I'm not sure that kind of rigorous Q/A approach is going to work in an
open source project, especially one like FDO where the user community is
fairly limited and nobody is in a position to offer guarantees.

I would hope that FDO could eventually take the same kind of steps that
MapGuide is for the open source release process; pushing the
build/installer responsibility out to the community and being agile
enough to quickly fix and release new point versions to deal with
defects that are not found during the beta/rc cycle. Not too quickly
though; especially if users are choosing not to take part in testing
against weekly and beta releases.

To deal with requirements such as Autodesk's to maintain stable code
streams outside of the open source release cycle, the MapGuide project
decided to allow contributors to maintain their own branches in the
"sandbox" area, with the understanding that any appropriate code changes
made in these sandbox areas would also be contributed back to trunk. I
think that this approach would address an earlier request of the FDO
project for maintaining branches of particular tags?

Jason

-----Original Message-----
From: Greg Boone
Sent: March-02-09 12:11 PM
Subject: Trying to Deploy FDO to Web

I think all changes at this point, and their proposed solution, should
be nominated for inclusion and discussed on the internals site. We have
to consider what level of testing would be required to ensure that the
proposed changes work as intended. Up until this point we have
benefitted from the fact that the Autodesk folks have been QA'ing our
builds as a part of their upcoming releases of MapGuide, etc. From my
understanding they will not be able to test FDO beyond build G044. Any
changes we make will have to be QA'ed by OSGeo members and guarantees
made that ensure the change is working as intended and does not break
any previous functionality.
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Greg Boone

RE: Relase process (was Trying to Deploy FDO to Web)

Reply Threaded

I do not disagree with anything you say. However, we have to have to follow some common sense principles too. I am not stating that Autodesk will determine which defects are submitted to the 3.4.0 release stream. I only state that someone has to QA proposed defect fixes once we get into Release Candidate territory. That can be Autodesk OSGeo members if they nominate a defect, or it can be done by other contributors as well. We have to have someone verify that a fix works outside the contributor that submits the fix.

I am all for pushing build/installer responsibility out to the community, but we are not there yet. Hopefully we can get that in place for the next release. As for Sandboxes/tags, that is fine as well. However, that does not deal with the possibility that a change made in the RC timeframe will not get adequate vetting approval. Bottom line, if a defect needs to be submitted at this point in the process, it needs to be tested by someone.

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Birch
Sent: Monday, March 02, 2009 3:46 PM
To: FDO Internals Mail List
Subject: [fdo-internals] Relase process (was Trying to Deploy FDO to Web)

Greg,

I'm not sure that kind of rigorous Q/A approach is going to work in an
open source project, especially one like FDO where the user community is
fairly limited and nobody is in a position to offer guarantees.

I would hope that FDO could eventually take the same kind of steps that
MapGuide is for the open source release process; pushing the
build/installer responsibility out to the community and being agile
enough to quickly fix and release new point versions to deal with
defects that are not found during the beta/rc cycle. Not too quickly
though; especially if users are choosing not to take part in testing
against weekly and beta releases.

To deal with requirements such as Autodesk's to maintain stable code
streams outside of the open source release cycle, the MapGuide project
decided to allow contributors to maintain their own branches in the
"sandbox" area, with the understanding that any appropriate code changes
made in these sandbox areas would also be contributed back to trunk. I
think that this approach would address an earlier request of the FDO
project for maintaining branches of particular tags?

Jason

-----Original Message-----
From: Greg Boone
Sent: March-02-09 12:11 PM
Subject: Trying to Deploy FDO to Web

I think all changes at this point, and their proposed solution, should
be nominated for inclusion and discussed on the internals site. We have
to consider what level of testing would be required to ensure that the
proposed changes work as intended. Up until this point we have
benefitted from the fact that the Autodesk folks have been QA'ing our
builds as a part of their upcoming releases of MapGuide, etc. From my
understanding they will not be able to test FDO beyond build G044. Any
changes we make will have to be QA'ed by OSGeo members and guarantees
made that ensure the change is working as intended and does not break
any previous functionality.
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Jason Birch

RE: RE: Relase process (was Trying to Deploy FDO to Web)

Reply Threaded

Yes, understood. I was probably just reading too much into your initial
message.

I don't have any problem with requiring testing of submissions at this
point in the cycle (actually, at any point in the cycle), just worried
that we don't that the resources to apply the kind of intensive Q/A that
a commercial product requires.

Jason

-----Original Message-----
From: Greg Boone
Sent: March-02-09 1:13 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: Relase process (was Trying to Deploy FDO to
Web)

I do not disagree with anything you say. However, we have to have to
follow some common sense principles too. I am not stating that Autodesk
will determine which defects are submitted to the 3.4.0 release stream.
I only state that someone has to QA proposed defect fixes once we get
into Release Candidate territory. That can be Autodesk OSGeo members if
they nominate a defect, or it can be done by other contributors as well.
We have to have someone verify that a fix works outside the contributor
that submits the fix.

I am all for pushing build/installer responsibility out to the
community, but we are not there yet. Hopefully we can get that in place
for the next release. As for Sandboxes/tags, that is fine as well.
However, that does not deal with the possibility that a change made in
the RC timeframe will not get adequate vetting approval. Bottom line, if
a defect needs to be submitted at this point in the process, it needs to
be tested by someone.

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Greg Boone

RE: RE: Relase process (was Trying to Deploy FDO to Web)

Reply Threaded

Let's take it issue by issue. I am willing to test the DELAYLOAD issue. We just will need someone to test the SQLServer Provider changes. Maybe I can convince Orest to do this in co-ordination with Brent.

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Birch
Sent: Monday, March 02, 2009 4:29 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Relase process (was Trying to Deploy FDO to Web)

Yes, understood. I was probably just reading too much into your initial
message.

I don't have any problem with requiring testing of submissions at this
point in the cycle (actually, at any point in the cycle), just worried
that we don't that the resources to apply the kind of intensive Q/A that
a commercial product requires.

Jason

-----Original Message-----
From: Greg Boone
Sent: March-02-09 1:13 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: Relase process (was Trying to Deploy FDO to
Web)

I do not disagree with anything you say. However, we have to have to
follow some common sense principles too. I am not stating that Autodesk
will determine which defects are submitted to the 3.4.0 release stream.
I only state that someone has to QA proposed defect fixes once we get
into Release Candidate territory. That can be Autodesk OSGeo members if
they nominate a defect, or it can be done by other contributors as well.
We have to have someone verify that a fix works outside the contributor
that submits the fix.

I am all for pushing build/installer responsibility out to the
community, but we are not there yet. Hopefully we can get that in place
for the next release. As for Sandboxes/tags, that is fine as well.
However, that does not deal with the possibility that a change made in
the RC timeframe will not get adequate vetting approval. Bottom line, if
a defect needs to be submitted at this point in the process, it needs to
be tested by someone.

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Greg Boone

RE: RE: Relase process (was Trying to Deploy FDO to Web)

Reply Threaded

I have talked to Orest and Brent. It appears their schedules are full for the next few weeks. I think it will be highly doubtful that the proposed SQL Server changes will make it into the 3.4.0 release. I am very hesitant to simply make the capabilities changes without robust testing in MapGuide. My recommendation at this point would be to release 3.4.0 and subsequently release a patch that contains the proposed changes for Tickets #469 and #470. Customers willing to test the patch can download it and determine its usefulness.

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Greg Boone
Sent: Monday, March 02, 2009 4:33 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Relase process (was Trying to Deploy FDO to Web)

Let's take it issue by issue. I am willing to test the DELAYLOAD issue. We just will need someone to test the SQLServer Provider changes. Maybe I can convince Orest to do this in co-ordination with Brent.

Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Birch
Sent: Monday, March 02, 2009 4:29 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Relase process (was Trying to Deploy FDO to Web)

Yes, understood. I was probably just reading too much into your initial
message.

I don't have any problem with requiring testing of submissions at this
point in the cycle (actually, at any point in the cycle), just worried
that we don't that the resources to apply the kind of intensive Q/A that
a commercial product requires.

Jason

-----Original Message-----
From: Greg Boone
Sent: March-02-09 1:13 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: Relase process (was Trying to Deploy FDO to
Web)

I do not disagree with anything you say. However, we have to have to
follow some common sense principles too. I am not stating that Autodesk
will determine which defects are submitted to the 3.4.0 release stream.
I only state that someone has to QA proposed defect fixes once we get
into Release Candidate territory. That can be Autodesk OSGeo members if
they nominate a defect, or it can be done by other contributors as well.
We have to have someone verify that a fix works outside the contributor
that submits the fix.

I am all for pushing build/installer responsibility out to the
community, but we are not there yet. Hopefully we can get that in place
for the next release. As for Sandboxes/tags, that is fine as well.
However, that does not deal with the possibility that a change made in
the RC timeframe will not get adequate vetting approval. Bottom line, if
a defect needs to be submitted at this point in the process, it needs to
be tested by someone.

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Jason Birch

RE: RE: Relase process (was Trying to Deploy FDO toWeb)

Reply Threaded

I should have replied to this earlier...

Yes, that sounds like a good approach.

Jason

-----Original Message-----
From: Greg Boone
Sent: March-03-09 8:37 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Relase process (was Trying to Deploy
FDO toWeb)

I have talked to Orest and Brent. It appears their schedules are full
for the next few weeks. I think it will be highly doubtful that the
proposed SQL Server changes will make it into the 3.4.0 release. I am
very hesitant to simply make the capabilities changes without robust
testing in MapGuide. My recommendation at this point would be to release
3.4.0 and subsequently release a patch that contains the proposed
changes for Tickets #469 and #470. Customers willing to test the patch
can download it and determine its usefulness.
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals