forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Addi <>
Subject Re: Project participation and hackability
Date Mon, 27 Jun 2005 10:58:51 GMT
Nicola Ken Barozzi wrote:

> Tim Williams wrote:
>> ....
>>> Imagine that all cutting-edge users can use the trunk in production. A
>>> patch is just a couple of actions away. And after incorporation, the
>>> check is instantaneous, and on a *real* test, as it actually get used.
>> I may be very well be in a unique situation but I can't imagine many
>> folks are able to run a trunk on a live production machine?  What
>> about the CM baggage?  If I were a client of that *real* test, I think
>> I'd be concerned.  If the recent JRE-version related discussion around
>> release time are any indiciation, this is not necessarily unique.
> I have a small company with about 15 people that use the Intranet 
> site. Being also a developer, I have no problem in using the latest 
> code in "production". It's a small percentage of all usages, but still 
> relevant for us.

>>> 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 said before that I do like a usable trunk (i.e. buildable + runnable
>> with no hoop jumping).
>>> 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.
>> 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.
>>> 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.
>>> 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.
> I have omitted another thing though, that I would like to release 
> Forrest *with* SVN stuff, so that patches can always be easy to make 
> and to send.
> As for the difficulty of maintaining a "releaseable" trunk, see my 
> next reply. Thanks for your mail, it helps :-)
I just wanted to pipe in here real quickly to add another data point to 
the discussion.  I am not a real dev, just a tweaker and poker, so most 
of this discussion is not really for me to get involved in but I do want 
to work with forrest and help as much as possible.  I do like the idea 
of a using trunk for production.  I am serving about 150 people on our 
intranet and wouldn't mind using it for our stuff.  We haven't 
implemented Forrest yet, but I plan to by October.  I already have our 
test system set up to run off trunk while I've been playing, so if trunk 
were always in a usable state, I don't have to change anything.


View raw message