forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: Project participation and hackability
Date Sun, 26 Jun 2005 02:22:18 GMT
Ross Gardler wrote:
> Nicola Ken Barozzi wrote:
> >This can only work if the trunk is always *usable*, and not only 
> >_buildable_. This can make our trunk be really bug-free, as there would 
> >really be a lot of eyes looking at the code.
> >
> >I would thus propose that the trunk be always *releaseable* at all 
> >times, and that all new functionality that interferes with usage of 
> >prior features be developed on separate branches.
> My random thoughts above are clearly a medium to long term goal, however 
> keeping trunk bug free can be achieved immediately. The question is, how?
> Do we *always* have a branch for development work, i.e. should we create 
> a 0.8-dev branch now and keep trunk for a possible 0.7.1 release? The 
> implications of this, that I can see, are that patches to 0.7 would also 
> have to be applied to 0.8-dev, but there shouldn't be a huge volume of 
> these.

Sounds like too many branches already. I would prefer a constantly
reliable trunk. Small changes get made on trunk. See my other reply
in this thread about test-before-commit.

Any substantial work gets done on a quick branch, e.g. our recent
docs-reorg-branch where we worked to get it finished and merged back ASAP.

What constitutes a substantial change?

> >Furthremore, these branches should merge whenever possible between them 
> >in a single branch so that they can be coded together, and get merged 
> >with the trunk only when all developer-known bugs are fixed.
> I'm not sure I follow how this will work. Can you provide an example?
> >This will also make it easier for us to release often, and to learn to 
> >make smaller reversible changes rather than big ones that are hard to 
> >understand by other developers and users.
> Yes, I like the idea of something like the following release schedule 
> (this may be incomplete, I'm doing it from memory):
> 0.8M1  - locationmap
> 0.8M2  - refactored core
> 0.8M3  - core as a plugin framework (assuming this is agreed upon ;-)
> 0.8RC1 - views (which incorporate the move to XHTML2 subset)
> 0.8

Why not just 0.8, 0.9, 0.10, 0.11, etc?

> If I understand what Nicola is saying each of these milestones would 
> become trunk at their release.

I thought that trunk is the release. All that we need to do is
freeze it for the release process.

What i would really like, is to not need to maintain release branches
as we are now.

> I note this release schedule would mean we could release 0.8M1 in a few 
> weeks time since the locationmap is very nearly there. This is a pretty 
> good argument for what Nicola (and Tim?) is saying regarding developing 
> in a branch then merging into trunk.
> >Let me know what you think.
> In principle I love it, especially the more managed release schedule. A 
> couple of requests for more detail though:
> How do we decide when we branch and when we work in trunk.

Yep, the big question. Perhaps trust each committer to know
when it is appropriate. If committers are unsure, then ask.

> How do we manage dependencies between different aspects of new work. For 
> example, Thorsten moved the views work to the locationmap branch because 
> he needed some of the locationmap work. However, now that seems to be 
> holding up the (easy) merging of the locationmap branch. What would be 
> the proper way of handling this?

Not to get into that situation again. The Locationmap branch was away
too long and the release process was delayed too much.


View raw message