Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Thu, 12 Jan 2006 10:12:03 +1100
From: David Crossley <crossley@apache.org>
To: dev@forrest.apache.org
Subject: Re: svn commit: r367799 - /forrest/branches/dispatcher/
Message-ID: <20060111231203.GA2021@igg.indexgeo.com.au>
References: <20060110213703.41767.qmail@minotaur.apache.org>
 <43C4329A.5010102@apache.org>
 <1136934067.8266.14.camel@localhost.localdomain>
 <43C4C396.3060700@apache.org>
 <1136974563.8242.98.camel@localhost.localdomain>
 <43C4E329.7040301@apache.org> <1136977584.8262.1.camel@localhost.localdomain>
 <43C4EB16.4080108@apache.org> <1137003746.8478.2.camel@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1137003746.8478.2.camel@localhost>
User-Agent: Mutt/1.4i

Thorsten Scherler wrote:
> Ross Gardler escribi??:
> > Thorsten Scherler wrote:
> > > Ross Gardler escribi??:
> > > Thorsten Scherler wrote:
> > > ...
> > > 
> > >>>yeah agree, so what do you suggest? Like said I do not see the point in
> > >>>a 100% copy if I change <5%.
> > >>
> > >>That is not how branching works. When you create a branch it only 
> > >>creates copies of the parts that are changed. Therefore, doing an "svn 
> > >>switch" is really quick and easy.
> > >>
> > >>Since you have found your requred changes will affect trunk, I'd suggest 
> > >>using a proper branch.
> > > 
> > > What speaks against "just create the final dispatcher
> > > plugins (like I did in the branch) in the trunk and leave v1 and v2 in
> > > our trunk till we have pelt contracts working with the dispatcher"?
> > 
> > I may have misunderstood, but I thought you said that your changes would 
> > couse problems in trunk and that is why you finally decided to use a 
> > "branch".
> 
> Yes and no. Yes if I use the v2 plugins directly, no if I start new
> plugins.

I too was confused about the previous statement that
the next phase of Dispatcher work would break trunk.
I presumed that that meant the current skins, hence
the need to branch. I also wondered if it meant that
the work was happening in the existing structurer and
themer plugins, hence the need to branch.

> > The only other thing that worries me is that there are already two 
> > different versions of views in whiteboard, you are now working on a 
> > thir. It is getting very confusing (your title is well deserved ;-).
>
> jeje ;-)

:-)

I too find the technique of copies of plugins confusing
and hard to manage and hard to keep documentation
up-to-date.

> I totally understand you and we need to clear out the confusion. Still I
> think creating 2 new plugins would be quickest and easiest way. I will
> start clearing the v1 plugins then we have the same number of
> plugins ;-)
> 
> wdyt?

That is still too many.

We should bear in mind that we have emphasised that
the Dispatcher work should not be relied upon. So we
are safe to make radical changes. We can assume that
whoever is using it, is also reading the dev list
with glee. They probably have a copy of a working svn
to manage their current website and local development,
and they have a local version of the matching docs.
Other brave souls are at the head of trunk, so no need
to worry about them.

So i reckon that we do not need to support versions
of rapid development work.

When the next minor hurdle of Dispatcher development
is ready in a branch, then we announce it on the
dev list and then just do it. Everyone then can decide
for themself whether to 'svn up' or not.

Our main Changes for 0.8-dev should state the major
changes (and perhaps the svn revision number) and
then the rest of the detailed changes are in the
plugin's status.xml file.

-David