Starting a 1.0 development (Re: [Proposal] rollback)

[Ross Gardler <rg...@apache.org>]

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

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

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

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.

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)

Ross

Re: Starting a 1.0 development (Re: [Proposal] rollback)

[David Crossley <cr...@apache.org>]

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