[fdo-internals] Relase process (was Trying to Deploy FDO to Web)

[Jason Birch]

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.