Some javascript/style in this post has been disabled (
why?)
I think that is the next logical step. I will try and put
together some notes for you on what I have been doing. This would also be a
good time to tweak the process/output to make it more maintainable and user
friendly.
From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Trevor Wekel
Sent: Wednesday, September 23, 2009 9:38 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] 3.4 update?
Not sure I want to suggest this because it is going to be a
bunch more work for me but...
For Fdo 3.5, should we move the open source builds to a
community managed machine? I am hosting a VMware virtualization
environment and spinning up one more VM wouldn’t kill me.
The MapGuide Open Source build machine is using Cruise Control
.Net. There was a bit of setup involved but the community chipped in so
it wasn’t brutal to do.
Thanks,
Trevor
From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone
Sent: September 23, 2009 6:34 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] 3.4 update?
I will see what can be done.
From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Jason Birch
Sent: Wednesday, September 23, 2009 2:12 AM
To: FDO Internals Mail List
Subject: [fdo-internals] 3.4 update?
Are there any plans to do a new build of 3.4 to pass along
the recent memory leak fixes, and to fix the provider naming issue with the
King Oracle provider?
I'm going to be releasing an RC for MapGuide 2.1 within the
next couple days, and if there was a patched windows build of FDO 3.4 to go
along with it, that would be very cool.
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
