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

[Greg Boone]

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: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] 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
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals