code freeze on dispatcher related resources in trunk

El sáb, 28-01-2006 a las 18:09 +1100, 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.

> 
> 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

> 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.

> 
> 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?
2) do we have plans to release 0.8 within a month?
3) did we decide to switch from skins to the dispatcher in a
0.8
release?

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. :(

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

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.

Good.

> > 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?

No.

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.

-David

David Crossley wrote:
> Thorsten Scherler wrote:

...

>>>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.

+1 - to do this we need a release candidate. This thread
makes it sound 
like Thorsten is ready for this.

We also need to do this with the locationmap stuff. Tims
work on caching 
has improved things considerably, but there are still
problems, I think.

See FOR-200

Perhaps we need a new "control" issue for the
dispatcher, much like 
for-200 is for the locationmap.

>>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.

Yes, I would propose releasing 0.8 with the dispatcher as a
plugin and 
the skins system clearly marked as "deprecated".
We should positively 
encourage users to stop using skins and switch to the
dispatcher.

The actual swap should happen in 0.9.

My reasoning is that we will have had more people testing
the dispatcher 
(I am continually hitting glitches with it at the moment -
but I'm using 
V2 so am not going into detail). In addition it will give us
more time 
to tidy up the docs and improve on performance (should it
still be 
needed after the v3 stuff).

Ross