[fdo-dev] SHP build broken in trunk

[Greg Boone]

Hi All,

I would like to provide some background on the decision made to branch
the fdo code into a 3.2.x branch. 

The Autodesk fdo team decided to branch the various fdo Subversion
repositories into 3.2.x streams for an upcoming release of Autodesk Map
scheduled for the April 2007 timeframe. We decided to branch early in
October based on the fact that the Map release process requires fairly
strict control over code submissions that go into the Map release once
an agreed on date has been reached. Basically, all code submissions made
to the Map code base have to be acceptable to the Map team and be
verifiable by the Map Quality Assurance processes. It was our opinion
that restricting code submissions to the Subversion trunk to those
defects verifiable and acceptable to the Map team from October until
April was too restrictive. Therefore the 3.2.x branch was created. We
also identified the fact that submissions to the 3.2.x branch were
valuable and useful to other fdo clients, therefore we implemented a
process of porting all code dropped in the branch back to the trunk. In
this manner, it was our objective that the trunk remain open to general
submissions from the non-Map client community.

Saying all that, this was the first branch and the first attempt at an
integration of an OSGeo Subversion release into the Autodesk Map
product. The PSC is still refining its processes and working on learning
from the experiences of the general fdo community. I am sure that once
Map ships in April we will have learned many lessons, from all parties
involved, that will influence the release/maintenance processes. To that
effect, the PSC has created an fdo process document and will be
tailoring that document with feedback from the community. 

The PSC looks forward to hearing from all parties on their experiences
with fdo and working with all clients to improve our processes.

Thanks,

Greg 

-----Original Message-----
From: Dan Stoica 
Sent: Thursday, November 09, 2006 12:56 PM
To: dev at fdo.osgeo.org
Subject: RE: [fdo-dev] SHP build broken in trunk

I totally agree with Mateusz.

That was my theory about branches as well. Once it's stabilezed it is
shipped as X.y release. Some features may be ported to other branches
but I don't see the reason to port everything.


Dan.

-----Original Message-----
From: Mateusz Loskot [mailto:mateusz at loskot.net] 
Sent: Thursday, November 09, 2006 12:48 PM
To: dev at fdo.osgeo.org
Subject: Re: [fdo-dev] SHP build broken in trunk

Dan Stoica wrote:
> BTW, I think this requirement to merge back to the trunk will be a 
> source of problems L

May I ask why FDO uses separate branch for "freezing" code and bug
fixing and then all stuff is merged back to trunk, instead of freezing
in the trunk?

>From my experience, the most popular procedure I've observed/used is:

1. Long development process in the trunk
2. It's time to freeze
2.1 An announce goes to all developers with request "Don't push
new features, only testing"
2.2 Bug fixes goes to trunk
2.3 It's stable, so let's release it
2.4 tag is created (not branch) with release snapshot:
tags/release-X.Y.Z
3. After release has been tagged, trunk is back for next development
cycle and accepts new features, etc.

Branches are used for longer forks for big features.
For instance, one wants to test new RDBI drivers design,
so he creates a private branch and applies new stuff.
After it's finished, tested and decided to be used in the main
development line, branch can be merged back to the trunk.
Usually, the next step is to create new release with this new big
feature and tag it (create named snapshot).

IMHO, private branch for bug fixing only and back-merging to trunk is
pretty complicated. Anyway, the trunk needs to freeze (close for new
features) for this cycle.

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe at fdo.osgeo.org
For additional commands, e-mail: dev-help at fdo.osgeo.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe at fdo.osgeo.org
For additional commands, e-mail: dev-help at fdo.osgeo.org