[fdo-dev] SHP build broken in trunk

[Dan Stoica]

" We selected option 2 so people are not constraint to drop code in the
trunk."

Robert, I agree. But how the above matches what are we currently doing?
This was my question.

Dan.

-----Original Message-----
From: Robert Fortin 
Sent: Thursday, November 09, 2006 1:43 PM
To: dev at fdo.osgeo.org
Subject: RE: [fdo-dev] SHP build broken in trunk

Mateusz,

That's one of the 2 approaches.  We can 1) closed the entire highway for
a while as you suggest or 2) leave some lanes opened and slow down
trafic a bit while people can still go throw (BTW I don't own that
example K.Fogel owns it
http://producingoss.com/html-chunk/development-cycle.html).  We selected
option 2 so people are not constraint to drop code in the trunk.  We
tried to delay the branch until the last moment. The 3.2.x branch can
have a life on its own for a long while which won't prevent merging to
happen.

It is the role of the PSC to decide on the branch strategy and when
branch has to occur.  The FDO PSC has just started and the decision to
use this branching strategy was taken before the PSC was put in place.
As member of PSC, it is up to you to bring this issue to the attention
of the PSC to discuss.

Ultimately I think that branching is unavoidable in order to stabilize
releases and continue major development in parallel. The trunk should be
were major development happen. 

RF 

-----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