Return-Path: 
 <dev-return-19985-apmail-forrest-dev-archive=forrest.apache.org@forrest.apache.org>
Delivered-To: apmail-forrest-dev-archive@www.apache.org
Received: (qmail 96076 invoked from network); 30 Sep 2005 14:50:57 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 30 Sep 2005 14:50:57 -0000
Received: (qmail 78628 invoked by uid 500); 30 Sep 2005 14:50:56 -0000
Delivered-To: apmail-forrest-dev-archive@forrest.apache.org
Received: (qmail 78583 invoked by uid 500); 30 Sep 2005 14:50:56 -0000
Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@forrest.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@forrest.apache.org>
List-Post: <mailto:dev@forrest.apache.org>
Reply-To: dev@forrest.apache.org
List-Id: <dev.forrest.apache.org>
Delivered-To: mailing list dev@forrest.apache.org
Received: (qmail 78572 invoked by uid 99); 30 Sep 2005 14:50:55 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Sep 2005 07:50:55 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Received: from [65.77.211.84] (HELO www2.kc.aoindustries.com) (65.77.211.84)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Sep 2005 07:51:01 -0700
Received: from fo2.kc.aoindustries.com (www2.kc.aoindustries.com
 [65.77.211.84])
	by www2.kc.aoindustries.com (8.13.1/8.13.1) with ESMTP id j8UEoWDq008073
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <dev@forrest.apache.org>; Fri, 30 Sep 2005 09:50:32 -0500
Received: from localhost (localhost [[UNIX: localhost]])
	by fo2.kc.aoindustries.com (8.13.1/8.13.1/Submit) id j8UEoVQ8008010
	for dev@forrest.apache.org; Fri, 30 Sep 2005 09:50:31 -0500
X-Authentication-Warning: fo2.kc.aoindustries.com: indexgeo set sender to
 crossley@apache.org using -f
Date: Sat, 1 Oct 2005 00:50:11 +1000
From: David Crossley <crossley@apache.org>
To: dev@forrest.apache.org
Subject: Re: Starting a 1.0 development  (Re: [Proposal] rollback)
Message-ID: <20050930145011.GA10794@igg.indexgeo.com.au>
References: <20050927235942.91569.qmail@minotaur.apache.org>
 <1127866095.11709.5.camel@localhost.localdomain>
 <200509272141.54103.diwaker@apache.org> <433A5053.3070802@apache.org>
 <20050929004632.GA3879@igg.indexgeo.com.au> <433BB72B.4010706@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <433BB72B.4010706@apache.org>
User-Agent: Mutt/1.4i
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
> >>Diwaker Gupta wrote:
> >>>Thorsten Scherler wrote:
> >>>
> >>>>>Added two new plugins for
> >>>>>refactoring views into the core:
> >>>>>- structurer
> >>>>>- themes
> >>>>>
> >>>>>Recent changes to views with using jxtg as core component
> >>>>>made the old view plugins unusable (FOR-675)
> >>>>>which can not longer stay like this.
> >>>>>
> >>>>>I recommend to rollback:
> >>>>>- org.apache.forrest.plugin.internal.view
> >>>>>- org.apache.forrest.plugin.output.viewHelper.xhtml
> >>>>>to revision -r280939 and then commit them back as views head.
> >>>
> >>>Why can't we just roll back trunk to a stable version, and move the 
> >>>views/xhtml2 work to a new branch? I think thats much neater, and easier 
> >>>both on devs and users alike. People can hack away on the views/xhtml2 
> >>>branch without having to worry about breaking trunk for someone.
> >>
> >>+1
> >>
> >>In fact this is exactly what we agreed in the IRC session:
> >>
> >>Sep 19 11:17:31 <tscherler>	- we should get the xhtml2 and view internal 
> >>together
> >>Sep 19 11:18:03 <tscherler>	- xhtml2 should be merged into the internal 
> >>views stuff, simply replace the docuemnt2html part
> >>Sep 19 11:18:42 <tscherler>	- x2 plugin should provide xdocs2x2 
> >>convertion
> >>Sep 19 11:19:17 <tscherler>	- views should work with x2 input
> >>Sep 19 11:21:15 <tscherler>	- we need to write a x2 to xhtml plugin
> >>Sep 19 11:21:52 <tscherler>	that should be basically a bunch of contracts
> >>Sep 19 11:22:19 <tscherler>	roadmap:
> >>Sep 19 11:22:31 <tscherler>	1) create new branch
> >>Sep 19 11:22:48 <tscherler>	2) move view stuff and x2 stuff into core
> >>Sep 19 11:23:10 <tscherler>	3) resolving by both only allowed through lm
> >>Sep 19 11:23:37 <tscherler>	4) create xdocs2x2 plugin
> >>Sep 19 11:24:10 <tscherler>	5) create x2 to xhtml plugin
> >>Sep 19 11:24:41 <tscherler>	in this branch all skins are removed
> >>Sep 19 11:24:52 <tscherler>	only view is supported
> >>Sep 19 11:25:19 <tscherler>	skin pipes are to be refactored to output 
> >>xhtml2
> >
> >Hold on. That IRC discussion was extremely rushed at the end.
> >We did not make any decisions there. Someone was going to make
> >a proposal. Are you sure that a branch is the way to do this?
> 
> Yes, you are right. Lets start discussing the proposal in the open.
> 
> >Branches tend to become islands of lone development, and when
> >they go on for too long, become hard to merge.
> 
> This work will touch pretty much *all* of Forrest. It will introduce:
> 
> - XHTML2 - rewrite of core processing pipelines
> - Views - rewrite of core processing pipelines
> - Locationmap - rewrite of core processing pipelines
> 
> So...
> 
> >How will this branch be merged? I see some confusing quick
> >comments in that IRC log, but no resolution.
> 
> We didn't foresee merging this branch, rather replacing the current trunk:
> 
> Sep 19 11:32:23 <tscherler>	that and is needed for an internal skin 
> plugin
> Sep 19 11:32:29 <rgardler>	David: after we merge this beast? -> I do 
> not see us merging this branch, I see this as a compelte rewrite
> Sep 19 11:32:40 <rgardler>	all the stripped out stuff goes in plugins
> Sep 19 11:32:54 <tscherler>	+1
> Sep 19 11:32:55 <rgardler>	we are lef with a really clean core that 
> does nothing but the structurer part
> Sep 19 11:33:30 <crossley>	radical. So we cease development on trunk?
> Sep 19 11:33:33 <rgardler>	If you know Eclipse you'll understand the 
> beuaty of this
> Sep 19 11:34:02 <rgardler>	if not, think of Jedit - similar concept,
> Sep 19 11:34:12 <rgardler>	JEdit does nothing but provide a text editor 
> and a plugin frameowrk
> Sep 19 11:34:33 <tscherler>	(02:33:47) crossley: radical. So we cease 
> development on trunk?-> basically it should become a stable branch
> Sep 19 11:34:47 <tscherler>	like cocoon-2.1.x
> Sep 19 11:34:51 <rgardler>	Yes, make a 0.8 release and only do bug fixes
> Sep 19 11:35:49 <tscherler>	that would not meet "usable trunk " approach 
> but we can have 0.8 branch for that
> Sep 19 11:35:58 <tscherler>	better 0.8.x
> Sep 19 11:36:27 <rgardler>	I think we are in the mechanics now, that is 
> easy to do onlist
> 
> And so here we are onlist ;-)

Thanks, that was a productive way to bring out the
information for the discussion that we needed to have.

> >The thing that really frightens me is the comment
> >"in this branch all skins are removed". Perhaps that is
> >what is needed, but we must decide and not just an offhand
> >comment in an IRC log.
> 
> Yes, you raised this issue onIRC too:
> 
> Sep 19 11:28:57 <crossley>	So the old "skins" still continue to 
> function?
> Sep 19 11:29:11 <crossley>	after we merge this beast?
> Sep 19 11:29:17 <tscherler>	no
> Sep 19 11:29:26 <rgardler>	We can make an internal plugin that provides 
> backward compatability
> Sep 19 11:29:33 <tscherler>	yes
> Sep 19 11:29:39 <rgardler>	I think we need to do that otherwise users 
> will not upgrade
> Sep 19 11:29:51 <tscherler>	+1
> Sep 19 11:30:00 <crossley>	rgardler: good but is that possible
> Sep 19 11:30:08 <tscherler>	yes it isd
> Sep 19 11:30:22 <rgardler>	Yes, at worst we simply take trunk and make 
> it a plugin ;-)
> Sep 19 11:30:31 <tscherler>	+1
> 
> In other words, core will *not* have skin functionality. It will only be 
> available in a (deprecated?) plugin.

Great, that makes a sigh of relief for the whole
community. If projects need to continue with skins
for a while then we can. Just that the Forrest project
will be putting all our effort into "views".

We need to document that approach for skins deprecation.
At least it is mentioned now here on list.

If no-one speaks up about that then we can take that
as a decision.

> >What was wrong with Thorsten's proposal to cease work
> >on the old plugins and create new plugins?
> 
> This is a complete rewrite of Forrest. Doing it in a plugin will 
> encorage us to reuse existing monolothic code in core.

Now i understand.

> If we had a 1.0 release already I would be proposing a 2.0 development. 
> But we don't have one so this is a 1.0 development.

So when that branch comes back to replace trunk,
would it become the 0.9 release after that?

We also said that if necessary we could go to
0.10, 0.11, etc.

> It could be the other way around. 0.8 becomes the branch and we do this 
> work in trunk. But I believe we need to have a "spring clean" (it must 
> be spring for one of our developers)

I gather that we cannot do such reconstruction in the
trunk because we decided to keep it usable and do major
things in branches.

So then trunk becomes a maintenance place for the next
release, i.e. release 0.8 now, then branch and do the
refactoring there, with only bugfixes in the trunk.
The website documentation gets published from this new
development branch.

Is that how others see it?

-David