forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Project participation and hackability
Date Mon, 27 Jun 2005 11:03:40 GMT
Nicola Ken Barozzi wrote:
> Tim Williams wrote:

>> This, however, is quite a committment.  While I'm for a usable trunk,
>> extending that though to a "releasable trunk" is more committment than
>> I'd want.  Maybe I'm reading too much into it but claiming that at any
>> given moment the trunk is [apache] release quality is bold.
> Ok, probably the wording is too strong.

Yes, I would prefer to think of it as trunk is always "release 
candidate" releasable. Meaning us devs would use it in production, so 
adventurous users should be able to as well.

We do a pretty good job of fixing users problems as they emerge. Looking 
at our user lists we have a number of active devs there and an 
increasing number of users helping users. I think we are strong enough 
to support milestone releases.

This, I believe, would be as close as we can reasonably get to "always 
releasable". We should consider making this a part of our release 
process. That is, once someone says "I think trunk is ready for a new 
release" we should consider making an RC release immediately. We should 
make announcements about this on our mail lists, but not in the wider 

Once we have an RC built we only allow bug fixes in trunk, new features 
are developer in a branch. Subsequent RC's for that release should be 
made every couple of weeks. Once we have a couple of weeks with no bug 
fixes we release.

Remember that plugins can have a separate release cycle. So only work on 
core need move to a branch.

>>> 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 understand that there will inevitably be dependencies between
>> branches but I don't care for merging branches into a single branch
>> (btw, wouldn't that ultimately become the defacto dev trunk?).
> There should not be dependencies between branches. If there is, then it 
> should merge in a single branch.

But this will prevent complete features being merged with trunk because 
incomplete features are brought into the branch. All that will happen 
there is that the branch will get into the state that trunk was in 
before the 0.7 release and we will split our devs between creating new 
features in the branch and maintaining trunk (not necessarily a bad 
thing, but do we have enough devs for this?)

>>> 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.
>>> Let me know what you think.
>> I guess the summary is that this sounds like an "Always-Branch" system
>> as opposed to the more pragmatic "Branch-When-Needed system" and that
>> seems overly rigid for little return.  In other words, I doubt that a
>> lot of folks are able to run a trunk in a production environment and
>> so burdening yourselves with the overhead of maintaining a trunk in a
>> "releasable state" for what would amount to a handful of folks that
>> could use it (and likely already have svn loaded anyway) doesn't seem
>> worth it.
> I am one of those, and I think that most Forrest developers are. If we 
> have at least a couple of others willing to use it, we're set.

A number of us devs appear to use trunk in production environments too 
(and at least one of us is using locationmap in a production as well). 
We can do so because we know the workarounds for the problems that 
exist. In addition, as I noted above, we are doing a superb community 
job of supporting our users. I think we can really capitalise on that at 
this point, just as long as trunk is not chock full of workarounds.

In other words, I am +1 for an "always RC quality" or an "always beta 
quality" (as Nicola said in another reply) trunk. I am also +1 for 
"alpha" quality branches where necessary.


View raw message