forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [Proposal] Development process and a stable trunk
Date Sat, 27 Aug 2005 14:14:41 GMT
Tim Williams wrote:
> On 8/26/05, Ross Gardler <rgardler@apache.org> wrote:
> 
>>Ferdinand Soethe wrote:
>>
>>
>>>I have an uncomfortable gut feeling with the current status of our
>>>pre-release version and I'd like your feedback on these concerns and
>>>my suggestions to change our process.
>>>
>>>
>>>My concerns with the current situation:
>>>
>>>- in the last few month a number of exciting major projects
>>> (location maps, views, i18n, change of cocoon ...)and a number of
>>> smaller ones have been developed (which is good!)
>>>
>>>- most of them have not been finished to the point of being releasable
>>> and (so it seems to me) will not be for considerable time so it
>>> seems like we won't be able to release quickly without a major clean-up
>>> effort (which I consider bad).
>>>
>>>- the work-in-progress-state and its (perfectly normal) unfinished
>>> documentation make it very hard for people to understand the
>>> development version or work with it at any point in time or
>>> understand the implications and side effects of each new development.
>>>
>>>What I'd like to see in the future:
>>>
>>>1 Adjust our development process so that the current development
>>> version (I think this is called 'trunk') is always releasable,
>>> stable and _well documented_ (meaning complete and correct, not well
>>> written or suitable for a dummy user).
> 
> 
> We've talked about this before and last time the only thing I had
> heartburn with was "always releasable" trunk as it implies an "Always
> Branch" system and I think that's overly rigid and runs counter to our
> community goals.  A reasonably stable trunk is a good goal.  Well
> documented to the extent possible - if something is still under heavy
> development then time shouldn't be wasted documenting yet (beyond that
> which would allow other devs to check it out).  Heavy development in
> the trunk?  Yes, if it's not causing the trunk to be unstable, then
> yes.

+1, my recollection of the previous discussion was that a branch is used 
for new functionality or major refactoring. My recollection of "always 
releasable" is that Forrest devs are using it in production 
environments. This implies that there may be one or two hidden bugs but 
in the main it is releasable.

In addition "always releasable" should mean that all tests are past 
(when we have them)

>>>2 Develop all major changes and new features in separate branches that
>>> will only be merged back into trunk when they are stable
>>> and well documented (not talking refined documentation but good enough
>>> that a technical writer could work with it) and a good number of committers
>>> not involved in the process have reviewed and tested them.
> 
> 
> Develop all major changes and new features *that may make the trunk
> unstable* in separate branches maybe.  As written, I think this would
> lead to fracturing in a couple ways.  1) devs wouldn't check-out all
> the other branches and new stuff would be sole-developed even more so
> than some things are now; 2) bleeding-edge users won't get into
> checking out multiple branches to checkout new functionality (i.e. no
> patches).

The reality of most work is that it starts of as a one person operation 
until it becomes usable, occasionally someone else comes along (as you 
did with Loationmaps). SVN does not force users to checkout complete 
branches. They simply run a switch command and that's it. this is a very 
fast operation in most cases.

Having said that, I agree with your concerns. It's difficult to decide 
when not to branch, often a simple change becomes something much more major.

>>Both 1 and 2 are already agreed in principle, we just have to action it
>>by creating the infrastructure and processes, see end of this mail for
>>links.
> 
> 
> I think we agreed to these goals (more or less):
> 1) a stable trunk (ie. no "hoop-jumping" to build and run). 
> 2) a branch for anything that would violate goal #1
> 3) each branch in #2 should be independent features (so that each can
> merge separately)
> 
> My take on what's being suggested goes well-beyond this but maybe I'm
> reading too much into it.

My take, is as you define it. Who knows exactly what Ferdinand meant 
(I'm sure he'll tell us if it is different). What we need to do is 
document it, this thread and the others I linked to in a previous reply 
go a long way to providing this documentation. We just need someone to 
have the time to pull it all together.


...

>>> This would also make testing of new releases a lot more focussed.
>>>
>>>
>>
>>I would like to go a step further and say we do not merge branches until
>>we have automated tests for the new features and all existing tests pass.
> 
> 
> I don't think we're mature enough for that.  At least, I've not seen a
> robust enough test harness around for it.

I don't understand how we can not be mature enough. In agile programming 
you write the tests *before* you write the code. We are a long way from 
that, but I don't see why we can't try and catch up a bit.

At the very least we should insist that the minimal testing we do have 
is passed (David as set up an instance of Forrest on our zone, we need 
to make use of this for testing).

In addition there are a number of testing frameworks that can be used 
for this. We have discussed it in the past. There are some basic 
starting points in the whiteboard.

However, I agree with both yourself and David in that the absence of 
these tests should not prevent us actoning this proposal (or whatever we 
agree on).

>>>5 As a supportive measure, clearly mark threads in this list when they
>>> deal with a particular branch so that people not working on that
>>> issue can safely ignore it.
>>>
>>>
>>
>>+1
> 
> 
> Encouraging such on the project would lead, in my opinion, to a
> fractured community.  People naturally tend to prioritize email based
> on the subject line, but supporting that through branch prefixes or
> the like would lead to several "mini-projects".  Heck, people might
> even set up email filters to only look at "their" branch -- not good. 
> I think instead we need folks periodically reminding everyone to write
> good archive/mailbox-friendly subject lines.

Yes, David and Thorsten have made similar points, I agree.

Ross

Mime
View raw message