forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: [Proposal] code freeze on dispatcher related resources in trunk
Date Sat, 28 Jan 2006 12:10:34 GMT
Thorsten Scherler wrote:
> David Crossley escribi??:
> > Thorsten Scherler wrote:
> > > 
> > > I propose a code freeze on *all* dispatcher related resources in trunk
> > > starting 28.01.2006 (hopefully ending 14.02.2006). 
> > > 
> > > I will create a real branch in the upcoming days (on the 28th or soonish
> > > after) from the current trunk where I would like to refactor the v2
> > > plugins to the dispatcher. 
> > > 
> > > I would like that all dispatcher related development will happen in this
> > > branch to secure that we will not get any conflict when merging back.
> > > 
> > > Thoughts, objections?
> > 
> > I too am not quite sure what the plan is.
> > 
> > Why do you need to branch? I am just trying to
> > make sure that we do only "branch when needed".
> I do not know anymore what to say since as soon I try to start the
> refactoring it seems I am doing it the "wrong way". ;-) I recommended to
> create two new plugins but then people started to say it is producing
> too much confusion. Now I followed their recommendation and people start
> the other way around.
> I am confused.

The problem was that you made a partial branch with
the two new plugins. No need.

> > Is it because the "themer" plugin in forrest/plugins
> > will have the same name as the current whiteboard plugin?
> Actually no. I thought to rename the structurer to
> org.apache.forrest.plugin.internal.dispatcher and the themer to
> org.apache.forrest.themes.core

Then that can be done in the whiteboard as normal.

> > Are there any changes to the actual core of Forrest
> > or is all the work contained in those two plugins?
> Everything is is in the plugins.
> > I suppose that one good reason to branch is that it
> > enables us to avoid these complications that we have
> > been having with "versions" of dispatcher amd mis-match
> > with docs.
> Hmm, yeah, but since the new system need a rewrite of parts of the docs
> it is marginal.
> > Also i suppose that this will let us remove all the
> > old views-related plugins from the whiteboard and do
> > a general tidy-up of dispatcher-related stuff. 
> I actually started it and am nearly finished in regard to views. I did
> not touch "old" documentation (<0.8) since back then we released with
> the views plugins v1.
> > Everything
> > will change when the branch merges, so that provides
> > a definite point for developers who use using the
> > older stuff in production.
> That is correct.
> > Normally we would develop in the whiteboard and when
> > we are satisfied, we decide to move it into forrest/plugins
> > However i gather that that cannot be done in this case.
> > Is that correct?
> No, it can be done like I always stated. I suggested the branch to
> satisfy those people who did not wanted just other dispatcher related
> plugins. Anyway all work *can* be done in 2 new plugins and without a
> branch (like I always stated) thanks to the great plugin system and the
> flexibility of the dispatcher.

Then that is the way that it should be done.

> > One thing does get me concerned. I wonder if you might be
> > rushing the merge, maybe to meet some non-project deadline.
> No, it is not because of my speech at the conference. It is for me a
> good motivation to finally finish the work of over 1 1/2 years but it is
> not the main motivation. I would like to see finally the dispatcher as
> official part of forrest since we reached a point where no major bugs
> can't be found.


> > Once we move the dispatcher out of the whiteboard then
> > we are saying that it is ready for prime time.
> Actually it is already prepared for prime time IMO, especially as soon I
> can start refactoring the current version because I will slim down the
> plugins to <50% of they current code. That said maybe I am not the one
> to state that it is ready for prime time because I know the dispatcher
> quite well. ;-) 
> > However it is not yet, so that might hold up our
> > 0.8 release.
> 1) why is it not ready?

A while ago i noticed big performance problems.
e.g. building site-author took four times as long.

We need to do at least basic profiling.

> 2) do we have plans to release 0.8 within a month?


The point of my comment was that merging branches can
hold up a release.

> 3) did we decide to switch from skins to the dispatcher in a 0.8
> release?

No, not even mentioned it yet. The last that i heard
was that 0.8 was going to be mainly about locationmap
with a test version of dispatcher-in-development.

However, it sounds like you have made huge gains. Good.

We would have a total documentation revision when that
switch happens.

> The only thing that is holding up my work right now is the endless
> discussion about *how* we should do the refactoring.
> I am tiered of this endless discussion and will follow what the forrest
> PMC decide, but please let us decide it once and for all. The only
> bummer is that I planed to start the work this weekend and actually did
> not plan anything else in my spare time and now I am sitting here
> waiting that this endless discussion is coming to an end and cannot do
> the work that needs to be done. :(

It should have just been done in the whiteboard then.
You should do that now. If we decide that there is
a need for a branch then that can still be done.


View raw message