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)
Subject: Re: [Proposal] code freeze on dispatcher related resources in trunk
From: Thorsten Scherler <thorsten@apache.org>
To: dev@forrest.apache.org
In-Reply-To: <20060128070944.GC25489@igg.indexgeo.com.au>
References: <1138299384.8853.74.camel@localhost>
	 <20060128070944.GC25489@igg.indexgeo.com.au>
Content-Type: text/plain; charset=utf-8
Date: Sat, 28 Jan 2006 12:46:52 +0100
Message-Id: <1138448812.8311.56.camel@localhost>
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable

El s=C3=A1b, 28-01-2006 a las 18:09 +1100, David Crossley escribi=C3=B3:
> Thorsten Scherler wrote:
> >=20
> > I propose a code freeze on *all* dispatcher related resources in trunk
> > starting 28.01.2006 (hopefully ending 14.02.2006).=20
> >=20
> > I will create a real branch in the upcoming days (on the 28th or soonis=
h
> > after) from the current trunk where I would like to refactor the v2
> > plugins to the dispatcher.=20
> >=20
> > I would like that all dispatcher related development will happen in thi=
s
> > branch to secure that we will not get any conflict when merging back.
> >=20
> > Thoughts, objections?
>=20
> I too am not quite sure what the plan is.
>=20
> 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.

>=20
> Is it because the "themer" plugin in forrest/plugins
> will have the same name as the current whiteboard plugin?
>=20

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

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

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.

>=20
> 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. ;-)=20

> 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
--=20
thorsten

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