forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: svn commit: r367799 - /forrest/branches/dispatcher/
Date Fri, 13 Jan 2006 12:36:11 GMT
David Crossley wrote:
> Ross Gardler wrote:
> 
>>David Crossley wrote:
>>
>>>David Crossley wrote:
>>>
>>>>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.
>>>
>>>What do people think? Is that the way that we should
>>>handle situations like this?
>>
>>I agree, it does seem cleaner.
>>
>>In fact, I was thinking of going a step further in the branch. At some 
>>point we need to move dispatcher into core and move the skins into 
>>plugins. Why not do that in the Branch. Thorsten seems pretty sure this 
>>next version is going to be "the one".
> 
> 
> It might be too soon to put it into core.
> We have not even done basic profiling of it
> to see its performance.

We can't profile it when it is not in core since the results would be 
totally different.

Sooner or later we have to take the leap. This is a major change, if we 
were a 1.0 product already this would make it a 2.0.

>>I for one would start using that branch for my own development work.
>>
>>I would see this branch as being work towards a 0.9 release.
>>
>>Thorsten?
> 
> 
> We had one email thread where we decided to
> only ever do small branches to fix certain specific
> issues then come quickly back to trunk. Never do
> multipurpose branches like we did with the locationmap
> and initial views mixup, where we got ourselves into trouble.

Putting dispatcher into core is certainly not a small change. In fact it 
is a massive change that cannot e done incrementally. I see no way of 
doing it other than in a branch.

The question is therefore, should we keep it in plugins for now.

> We had another email thread where we talked about
> (decided?) to do everything in a branch, then replace
> trunk with it. That frightened me, but from memory
> Ross made some placating points. Where is that old
> discussion?

Oh boy - don't tell me I am contradicting myself ;-)

Lets see what others think and dig out that thread.

Ross

Mime
View raw message