[VOTE] merge locationmap branch with trunk

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

With 0.7 finally out (congratulations everyone by the way, great work).

I'd like to take a vote on merging the locationmap branch with trunk. 
The changes over there are:

Locationmap
-----------

This is pretty much functional, but not in any way complete. There are a 
couple of outstanding patches from Tim Williams that extend 
functionality (sorry Tim I will apply them very soon, I've been quite 
distracted by other things lately).

The locationmap is backward compatible with 0.7, although the error 
returned for missing documents is currently a little confusing, this 
should be improved as a matter of urgency.

Views
-----

Lots of work has been happening on views over there. These are totally 
optional as they are whiteboard plugins.

Daisy Plugin
------------

This is version 0.2-dev of the daisy plugin. It is a whiteboard plugin 
and uses the locationmap to determine where to retrieve files. 0.3 will 
then go on to retrieve the XML flies from the repository rather than 
retrieve the HTML files from the wiki application.

----------------

As far as I am aware there are no changes that will break existing 
sites. However, you may want to test this before voting (I have not 
tested this before calling the vote but you can assume I will do so 
before actually merging).

Of course I am +1 for this merge.

Ross

Re: Project participation and hackability

[Nicola Ken Barozzi <ni...@apache.org>]

David Crossley wrote:
...
> I would prefer a constantly reliable trunk. Small changes get made on
> trunk. See my other reply in this thread about test-before-commit.

Here it is:

"
 > I hope that you are still talking about the Branch-When-Needed system.
 > http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html
 >
 > That is the closest to what we have been doing until now.
"

Yes, the point is: when is it _needed_? (like you ask below)
When changes are known not to be bug-free by the developer himself.

"
 > However, we are not diligent enough at the test-before-commit phase.
 > Forrestbot on the server would assist, but not replace that need.
"

Testing is good, but if changes are too big, testing is more difficult 
to do.

> Any substantial work gets done on a quick branch, e.g. our recent
> docs-reorg-branch where we worked to get it finished and merged back ASAP.
> 
> What constitutes a substantial change?

Simple. Every change that cannot be considered complete in a single 
commit, and that still has bugs that are known to the developer.

For example, Ross has said that there are still a couple of known 
problems in the locationmap branch. We cannot merge things we know are 
not ready. Same thing for the views, that are still in need of refinement.

We could say that the trunk should always be beta quality, that is 
already alpha-tested by developers.

>>>Furthremore, these branches should merge whenever possible between them 
>>>in a single branch so that they can be coded together, and get merged 
>>>with the trunk only when all developer-known bugs are fixed.
>>
>>I'm not sure I follow how this will work. Can you provide an example?

You and Thorsten know that your branches have bugs, but you need/want to 
merge. So do it, but on a locationmap-views branch. When you both don't 
have the knowledge of bugs on the previously used features, you can then 
merge with the trunk.

>>>This will also make it easier for us to release often, and to learn to 
>>>make smaller reversible changes rather than big ones that are hard to 
>>>understand by other developers and users.
>>
>>Yes, I like the idea of something like the following release schedule 
>>(this may be incomplete, I'm doing it from memory):
>>
>>0.8M1  - locationmap
>>0.8M2  - refactored core
>>0.8M3  - core as a plugin framework (assuming this is agreed upon ;-)
>>0.8RC1 - views (which incorporate the move to XHTML2 subset)
>>0.8
> 
> Why not just 0.8, 0.9, 0.10, 0.11, etc?

+1

>>If I understand what Nicola is saying each of these milestones would 
>>become trunk at their release.
> 
> I thought that trunk is the release. All that we need to do is
> freeze it for the release process.

Bingo.

releasable != can be zipped and released as-is
releasable == can be frozen and pushed to release after beta testing

In this way Forrest developers can decide to release Forrest at any 
time, without having to wait that a developer of a new feature fixes 
bugs or having to spend time understanding something that is still broken.

> What i would really like, is to not need to maintain release branches
> as we are now.

Exactly.

>>I note this release schedule would mean we could release 0.8M1 in a few 
>>weeks time since the locationmap is very nearly there. This is a pretty 
>>good argument for what Nicola (and Tim?) is saying regarding developing 
>>in a branch then merging into trunk.
>>
>>>Let me know what you think.
>>
>>In principle I love it, especially the more managed release schedule. A 
>>couple of requests for more detail though:
>>
>>How do we decide when we branch and when we work in trunk.
> 
> Yep, the big question. Perhaps trust each committer to know
> when it is appropriate. If committers are unsure, then ask.

+1

>>How do we manage dependencies between different aspects of new work. For 
>>example, Thorsten moved the views work to the locationmap branch because 
>>he needed some of the locationmap work. However, now that seems to be 
>>holding up the (easy) merging of the locationmap branch. What would be 
>>the proper way of handling this?
> 
> Not to get into that situation again. The Locationmap branch was away
> too long and the release process was delayed too much.

It can happen when features are so important and "core" to Forrest. In 
general it would not happen.


-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: Project participation and hackability

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

David Crossley wrote:
> Ross Gardler wrote:
> 
>>Nicola Ken Barozzi wrote:
>>

...

>>>This will also make it easier for us to release often, and to learn to 
>>>make smaller reversible changes rather than big ones that are hard to 
>>>understand by other developers and users.
>>
>>Yes, I like the idea of something like the following release schedule 
>>(this may be incomplete, I'm doing it from memory):
>>
>>0.8M1  - locationmap
>>0.8M2  - refactored core
>>0.8M3  - core as a plugin framework (assuming this is agreed upon ;-)
>>0.8RC1 - views (which incorporate the move to XHTML2 subset)
>>0.8
> 
> 
> Why not just 0.8, 0.9, 0.10, 0.11, etc?

No reason, my mind is just stuck in the current roadmap we have on Jira.

+1 for 0.8, 0.9.

Ross

Re: Project participation and hackability

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

Ross Gardler wrote:
> Nicola Ken Barozzi wrote:
> 
> >This can only work if the trunk is always *usable*, and not only 
> >_buildable_. This can make our trunk be really bug-free, as there would 
> >really be a lot of eyes looking at the code.
> >
> >I would thus propose that the trunk be always *releaseable* at all 
> >times, and that all new functionality that interferes with usage of 
> >prior features be developed on separate branches.
> 
> My random thoughts above are clearly a medium to long term goal, however 
> keeping trunk bug free can be achieved immediately. The question is, how?
> 
> Do we *always* have a branch for development work, i.e. should we create 
> a 0.8-dev branch now and keep trunk for a possible 0.7.1 release? The 
> implications of this, that I can see, are that patches to 0.7 would also 
> have to be applied to 0.8-dev, but there shouldn't be a huge volume of 
> these.

Sounds like too many branches already. I would prefer a constantly
reliable trunk. Small changes get made on trunk. See my other reply
in this thread about test-before-commit.

Any substantial work gets done on a quick branch, e.g. our recent
docs-reorg-branch where we worked to get it finished and merged back ASAP.

What constitutes a substantial change?

> >Furthremore, these branches should merge whenever possible between them 
> >in a single branch so that they can be coded together, and get merged 
> >with the trunk only when all developer-known bugs are fixed.
> 
> I'm not sure I follow how this will work. Can you provide an example?
> 
> >This will also make it easier for us to release often, and to learn to 
> >make smaller reversible changes rather than big ones that are hard to 
> >understand by other developers and users.
> 
> Yes, I like the idea of something like the following release schedule 
> (this may be incomplete, I'm doing it from memory):
> 
> 0.8M1  - locationmap
> 0.8M2  - refactored core
> 0.8M3  - core as a plugin framework (assuming this is agreed upon ;-)
> 0.8RC1 - views (which incorporate the move to XHTML2 subset)
> 0.8

Why not just 0.8, 0.9, 0.10, 0.11, etc?

> If I understand what Nicola is saying each of these milestones would 
> become trunk at their release.

I thought that trunk is the release. All that we need to do is
freeze it for the release process.

What i would really like, is to not need to maintain release branches
as we are now.

> I note this release schedule would mean we could release 0.8M1 in a few 
> weeks time since the locationmap is very nearly there. This is a pretty 
> good argument for what Nicola (and Tim?) is saying regarding developing 
> in a branch then merging into trunk.
> 
> >Let me know what you think.
> 
> In principle I love it, especially the more managed release schedule. A 
> couple of requests for more detail though:
> 
> How do we decide when we branch and when we work in trunk.

Yep, the big question. Perhaps trust each committer to know
when it is appropriate. If committers are unsure, then ask.

> How do we manage dependencies between different aspects of new work. For 
> example, Thorsten moved the views work to the locationmap branch because 
> he needed some of the locationmap work. However, now that seems to be 
> holding up the (easy) merging of the locationmap branch. What would be 
> the proper way of handling this?

Not to get into that situation again. The Locationmap branch was away
too long and the release process was delayed too much.

-David

Re: Project participation and hackability

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

Nicola Ken Barozzi wrote:
> The goal is to increase developer participation and involvment in the 
> Forrest Project, by reducing the barrier to entry.

I like that goal, you have my attention.

> There is another point which I find very important:
> 
>                _hackability_
> 
> A project should be hackable, so that users can *quickly* tweak the code 
> and make patches, changes, enhancements.

...

>  - modular
> 
>    In this way it can be hacked in small chunks, which are more
>    easily undertstandable. Sitemap separation has done something,
>    but the locationmap will be a big improvement, separating
>    location resolving and transformation processing

In addition there is still a fair bit of stuff in core that could be 
moved out to a plugin. I've recently been thinking that core should be 
nothing more than a framework to support plugins. That is core itself is 
only responsible for ensuring the data goes to the right place at the 
right time, there is no actual functionality in there.

This is in line with the goal of making views part of core whilst 
leaving the viewHelpers as a new type of plugin.

This is exactly what the Eclipse platform is. You can download the 
platform and have nothing but an empty desktop application whose only 
capability is to download and install plugins to make it do what you want.

Anyone who has built an application on Eclipse will know just how 
powerful this is.

> Imagine that you have Forrest in production, and that you find a bug. 
> Ok, so you look in the code, find it, and fix it. Now what? You have to 
> send a patch... 

...

> It's tooooooo long and tedious. In many cases I have resisted 
> sending patches for lack of time.

...

> "What the heck" - I thought - "too much hassle. If I could just use the 
> trunk in production, it would be much easier".
> 
> Imagine that all cutting-edge users can use the trunk in production. A 
> patch is just a couple of actions away. And after incorporation, the 
> check is instantaneous, and on a *real* test, as it actually get used.

+1

========================================================================

This section is Random Thoughts
-------------------------------

The particular strength of Forrest being a framework for a collection of 
plugins is that a user need not be responsible for updating from SVN. 
With the new versioned plugin code a user can opt to stick with a stable 
version, or can opt to use the latest dev version.

If can use this to add:

- an auto update facility (say every X builds)
- an auto test after the update is done (tests using the a real site)
- an auto reporting of failed tests
- auto reverting of failed plugins

What we end up with is a user installed system that is will always be 
the latest version of everything (that works).

We can even add a facility that detects when the user has modified a 
plugin locally and (with the users permission) creates a patch and 
submits it to Jira for them. Now I reckon that makes it easier enough. 
Nicolas patch submission scenario becomes:

1. do the fix
2. "forrest site -Dforrest.updatePlugins=true"
	- the system notices a change and creates a patch file against
	  the latest svn code
3. user is asked if the patch can be submitted and provides a comment

It is likely that many of these patches will be hacks and will not be 
applied "as-is", maybe we will want to add code to turn a new feature 
on/off. But it does mean we can see what our users want the system to 
do, and they don't even have to write an email.

(ho-hum this is a small part of what I did in my PhD studies I have a 
450 page thesis on the implications of this kind of system, but I'll 
summarise in just three words - "lets do it" - if anyone is interested 
in using this technique to build software automatically take a look at 
http://www.saafe.org - this hasn't been updated for a long time, but the 
basic idea is there)

Clearly the tests do not verify that the pages are rendered correctly 
(in terms of what the human sees). For this we need a new testing 
framework. This would be brilliant to have, but I don't think it will 
arrive soon (if anyone is interested Cocoon have been looking at 
automated HTML unit tests recently, their dev lists should turn up some 
interesting info).

End of Random Thoughts
----------------------
=======================================================================

> This can only work if the trunk is always *usable*, and not only 
> _buildable_. This can make our trunk be really bug-free, as there would 
> really be a lot of eyes looking at the code.
> 
> I would thus propose that the trunk be always *releaseable* at all 
> times, and that all new functionality that interferes with usage of 
> prior features be developed on separate branches.

My random thoughts above are clearly a medium to long term goal, however 
keeping trunk bug free can be achieved immediately. The question is, how?

Do we *always* have a branch for development work, i.e. should we create 
a 0.8-dev branch now and keep trunk for a possible 0.7.1 release? The 
implications of this, that I can see, are that patches to 0.7 would also 
have to be applied to 0.8-dev, but there shouldn't be a huge volume of 
these.

> Furthremore, these branches should merge whenever possible between them 
> in a single branch so that they can be coded together, and get merged 
> with the trunk only when all developer-known bugs are fixed.

I'm not sure I follow how this will work. Can you provide an example?

> This will also make it easier for us to release often, and to learn to 
> make smaller reversible changes rather than big ones that are hard to 
> understand by other developers and users.

Yes, I like the idea of something like the following release schedule 
(this may be incomplete, I'm doing it from memory):

0.8M1  - locationmap
0.8M2  - refactored core
0.8M3  - core as a plugin framework (assuming this is agreed upon ;-)
0.8RC1 - views (which incorporate the move to XHTML2 subset)
0.8

If I understand what Nicola is saying each of these milestones would 
become trunk at their release.

I note this release schedule would mean we could release 0.8M1 in a few 
weeks time since the locationmap is very nearly there. This is a pretty 
good argument for what Nicola (and Tim?) is saying regarding developing 
in a branch then merging into trunk.

> Let me know what you think.

In principle I love it, especially the more managed release schedule. A 
couple of requests for more detail though:

How do we decide when we branch and when we work in trunk.

How do we manage dependencies between different aspects of new work. For 
example, Thorsten moved the views work to the locationmap branch because 
he needed some of the locationmap work. However, now that seems to be 
holding up the (easy) merging of the locationmap branch. What would be 
the proper way of handling this?

Ross

Re: Project participation and hackability

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

Tim Williams wrote:
> Since this is about project process, hopefully by my opinions I'm not
> violating some unspoken pmc-only line here...

We are a very open community. We do not discuss anything like this in 
private. The only stuff that goes on in private is votes for new 
committers and internal Apache stuff. Everyone should feel that their 
opinion is extremely valuable to the project.

I'm not replying to your points here because they are all mirrored by 
other people in other mails on this thread, so I am trying to avoid 
repeating myself.

Ross

Re: Project participation and hackability

[Addi <ad...@rocktreesky.com>]

Nicola Ken Barozzi wrote:

> Tim Williams wrote:
>
>> ....
>>
>>> Imagine that all cutting-edge users can use the trunk in production. A
>>> patch is just a couple of actions away. And after incorporation, the
>>> check is instantaneous, and on a *real* test, as it actually get used.
>>
>>
>> I may be very well be in a unique situation but I can't imagine many
>> folks are able to run a trunk on a live production machine?  What
>> about the CM baggage?  If I were a client of that *real* test, I think
>> I'd be concerned.  If the recent JRE-version related discussion around
>> release time are any indiciation, this is not necessarily unique.
>
>
> I have a small company with about 15 people that use the Intranet 
> site. Being also a developer, I have no problem in using the latest 
> code in "production". It's a small percentage of all usages, but still 
> relevant for us.

>
>>> This can only work if the trunk is always *usable*, and not only
>>> _buildable_. This can make our trunk be really bug-free, as there would
>>> really be a lot of eyes looking at the code.
>>
>>
>> I said before that I do like a usable trunk (i.e. buildable + runnable
>> with no hoop jumping).
>>
>>> I would thus propose that the trunk be always *releaseable* at all
>>> times, and that all new functionality that interferes with usage of
>>> prior features be developed on separate branches.
>>
>>
>> This, however, is quite a committment.  While I'm for a usable trunk,
>> extending that though to a "releasable trunk" is more committment than
>> I'd want.  Maybe I'm reading too much into it but claiming that at any
>> given moment the trunk is [apache] release quality is bold.
>
>
> Ok, probably the wording is too strong.
>
>>> Furthremore, these branches should merge whenever possible between them
>>> in a single branch so that they can be coded together, and get merged
>>> with the trunk only when all developer-known bugs are fixed.
>>
>>
>> I understand that there will inevitably be dependencies between
>> branches but I don't care for merging branches into a single branch
>> (btw, wouldn't that ultimately become the defacto dev trunk?).
>
>
> There should not be dependencies between branches. If there is, then 
> it should merge in a single branch.
>
>>> This will also make it easier for us to release often, and to learn to
>>> make smaller reversible changes rather than big ones that are hard to
>>> understand by other developers and users.
>>>
>>> Let me know what you think.
>>
>>
>> I guess the summary is that this sounds like an "Always-Branch" system
>> as opposed to the more pragmatic "Branch-When-Needed system" and that
>> seems overly rigid for little return.  In other words, I doubt that a
>> lot of folks are able to run a trunk in a production environment and
>> so burdening yourselves with the overhead of maintaining a trunk in a
>> "releasable state" for what would amount to a handful of folks that
>> could use it (and likely already have svn loaded anyway) doesn't seem
>> worth it.
>
>
> I am one of those, and I think that most Forrest developers are. If we 
> have at least a couple of others willing to use it, we're set.
>
> I have omitted another thing though, that I would like to release 
> Forrest *with* SVN stuff, so that patches can always be easy to make 
> and to send.
>
> As for the difficulty of maintaining a "releaseable" trunk, see my 
> next reply. Thanks for your mail, it helps :-)
>
I just wanted to pipe in here real quickly to add another data point to 
the discussion.  I am not a real dev, just a tweaker and poker, so most 
of this discussion is not really for me to get involved in but I do want 
to work with forrest and help as much as possible.  I do like the idea 
of a using trunk for production.  I am serving about 150 people on our 
intranet and wouldn't mind using it for our stuff.  We haven't 
implemented Forrest yet, but I plan to by October.  I already have our 
test system set up to run off trunk while I've been playing, so if trunk 
were always in a usable state, I don't have to change anything.

Addi

Re: Project participation and hackability

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

Nicola Ken Barozzi wrote:
> Ross Gardler wrote:
> ...
> 
>> Once we have an RC built we only allow bug fixes in trunk, new 
>> features are developer in a branch. 
> 
> 
> I wouldn't be that strong. If I'm adding a new feature to the trunk, but 
> this does not interfere with prior behaviour, there are no problems.
> It's just about keeping the trunk possibly bug-free, as far as the 
> developer is concerned.

The above was only when we were in the "moving to a release state" i.e. 
we had actually build and released a release candidate. During normal 
development I would agree on branches for major work only.

>> But this will prevent complete features being merged with trunk 
>> because incomplete features are brought into the branch. All that will 
>> happen there is that the branch will get into the state that trunk was 
>> in before the 0.7 release and we will split our devs between creating 
>> new features in the branch and maintaining trunk (not necessarily a 
>> bad thing, but do we have enough devs for this?)
> 
> 
> We should not get into a situation in which an incomplete feature merges 
> with a more complete branch. This happens when development is too long, 
> and people start using the branch as their trunk.

Right, I get it now. That is what David said with respect to the 
locationmap branch, views and the delay on the 0.7 release.

Ross

Re: Project participation and hackability

[Nicola Ken Barozzi <ni...@apache.org>]

Ross Gardler wrote:
...
> Once we have an RC built we only allow bug fixes in trunk, new features 
> are developer in a branch. 

I wouldn't be that strong. If I'm adding a new feature to the trunk, but 
this does not interfere with prior behaviour, there are no problems.
It's just about keeping the trunk possibly bug-free, as far as the 
developer is concerned.

If we use branches for all new features, we have the problem that nobody 
will check what is happening, like with views. We should really push for 
small reversible changes in the trunk, and use branches only when this 
is not possible (like in a new feature that needs core refactoring).

Smaller changes are more easily testable, reversible, and auditable by 
all. Big commits tend to go by without peer review.

> Subsequent RC's for that release should be 
> made every couple of weeks. Once we have a couple of weeks with no bug 
> fixes we release.
>
> Remember that plugins can have a separate release cycle. So only work on 
> core need move to a branch.

Yup, that's cool :-)

>>>> Furthremore, these branches should merge whenever possible between them
>>>> in a single branch so that they can be coded together, and get merged
>>>> with the trunk only when all developer-known bugs are fixed.
>>>
>>> I understand that there will inevitably be dependencies between
>>> branches but I don't care for merging branches into a single branch
>>> (btw, wouldn't that ultimately become the defacto dev trunk?).
>>
>> There should not be dependencies between branches. If there is, then 
>> it should merge in a single branch.
> 
> But this will prevent complete features being merged with trunk because 
> incomplete features are brought into the branch. All that will happen 
> there is that the branch will get into the state that trunk was in 
> before the 0.7 release and we will split our devs between creating new 
> features in the branch and maintaining trunk (not necessarily a bad 
> thing, but do we have enough devs for this?)

We should not get into a situation in which an incomplete feature merges 
with a more complete branch. This happens when development is too long, 
and people start using the branch as their trunk.

If this is not possible, it's the most incomplete feature that must 
incorporate the changes from the more complete one, not the opposite. 
This frees it from being stopped in merging with the trunk.

...
> In other words, I am +1 for an "always RC quality" or an "always beta 
> quality" (as Nicola said in another reply) trunk. I am also +1 for 
> "alpha" quality branches where necessary.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: Project participation and hackability

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

Nicola Ken Barozzi wrote:
> Tim Williams wrote:


>> This, however, is quite a committment.  While I'm for a usable trunk,
>> extending that though to a "releasable trunk" is more committment than
>> I'd want.  Maybe I'm reading too much into it but claiming that at any
>> given moment the trunk is [apache] release quality is bold.
> 
> 
> Ok, probably the wording is too strong.

Yes, I would prefer to think of it as trunk is always "release 
candidate" releasable. Meaning us devs would use it in production, so 
adventurous users should be able to as well.

We do a pretty good job of fixing users problems as they emerge. Looking 
at our user lists we have a number of active devs there and an 
increasing number of users helping users. I think we are strong enough 
to support milestone releases.

This, I believe, would be as close as we can reasonably get to "always 
releasable". We should consider making this a part of our release 
process. That is, once someone says "I think trunk is ready for a new 
release" we should consider making an RC release immediately. We should 
make announcements about this on our mail lists, but not in the wider 
community.

Once we have an RC built we only allow bug fixes in trunk, new features 
are developer in a branch. Subsequent RC's for that release should be 
made every couple of weeks. Once we have a couple of weeks with no bug 
fixes we release.

Remember that plugins can have a separate release cycle. So only work on 
core need move to a branch.

>>> Furthremore, these branches should merge whenever possible between them
>>> in a single branch so that they can be coded together, and get merged
>>> with the trunk only when all developer-known bugs are fixed.
>>
>>
>> I understand that there will inevitably be dependencies between
>> branches but I don't care for merging branches into a single branch
>> (btw, wouldn't that ultimately become the defacto dev trunk?).
> 
> 
> There should not be dependencies between branches. If there is, then it 
> should merge in a single branch.

But this will prevent complete features being merged with trunk because 
incomplete features are brought into the branch. All that will happen 
there is that the branch will get into the state that trunk was in 
before the 0.7 release and we will split our devs between creating new 
features in the branch and maintaining trunk (not necessarily a bad 
thing, but do we have enough devs for this?)

>>> This will also make it easier for us to release often, and to learn to
>>> make smaller reversible changes rather than big ones that are hard to
>>> understand by other developers and users.
>>>
>>> Let me know what you think.
>>
>>
>> I guess the summary is that this sounds like an "Always-Branch" system
>> as opposed to the more pragmatic "Branch-When-Needed system" and that
>> seems overly rigid for little return.  In other words, I doubt that a
>> lot of folks are able to run a trunk in a production environment and
>> so burdening yourselves with the overhead of maintaining a trunk in a
>> "releasable state" for what would amount to a handful of folks that
>> could use it (and likely already have svn loaded anyway) doesn't seem
>> worth it.
> 
> 
> I am one of those, and I think that most Forrest developers are. If we 
> have at least a couple of others willing to use it, we're set.

A number of us devs appear to use trunk in production environments too 
(and at least one of us is using locationmap in a production as well). 
We can do so because we know the workarounds for the problems that 
exist. In addition, as I noted above, we are doing a superb community 
job of supporting our users. I think we can really capitalise on that at 
this point, just as long as trunk is not chock full of workarounds.

In other words, I am +1 for an "always RC quality" or an "always beta 
quality" (as Nicola said in another reply) trunk. I am also +1 for 
"alpha" quality branches where necessary.

Ross

Re: Project participation and hackability

[Nicola Ken Barozzi <ni...@apache.org>]

Tim Williams wrote:
> Since this is about project process, hopefully by my opinions I'm not
> violating some unspoken pmc-only line here...

Not at all! Everyone is very welcome to participate in the discussion, 
we need every help we can get. :-)

> On 6/25/05, Nicola Ken Barozzi <ni...@apache.org> wrote:
> 
...
> <related>
> As one whose recently climbed that barrier, I'd suggest that the
> largest barrier of entry to forrest development is it's own cocoon
> foundations.  While patches, trunks, and branches are common, sitemaps
> and other cocooon concepts take a lot of learning (== time
> investment==barrier).  Of course, I could just be the slow one of the
> crowd too.  I suspect I'm not the only one that looked at forrest and
> had the initial question, "where's the code?"
> </related>

;-)

I hope that making it all into smaller chunks will somewhat ease teh 
problems.

> ....
> 
>>Imagine that all cutting-edge users can use the trunk in production. A
>>patch is just a couple of actions away. And after incorporation, the
>>check is instantaneous, and on a *real* test, as it actually get used.
> 
> I may be very well be in a unique situation but I can't imagine many
> folks are able to run a trunk on a live production machine?  What
> about the CM baggage?  If I were a client of that *real* test, I think
> I'd be concerned.  If the recent JRE-version related discussion around
> release time are any indiciation, this is not necessarily unique.

I have a small company with about 15 people that use the Intranet site. 
Being also a developer, I have no problem in using the latest code in 
"production". It's a small percentage of all usages, but still relevant 
for us.

>>This can only work if the trunk is always *usable*, and not only
>>_buildable_. This can make our trunk be really bug-free, as there would
>>really be a lot of eyes looking at the code.
> 
> I said before that I do like a usable trunk (i.e. buildable + runnable
> with no hoop jumping).
> 
>>I would thus propose that the trunk be always *releaseable* at all
>>times, and that all new functionality that interferes with usage of
>>prior features be developed on separate branches.
> 
> This, however, is quite a committment.  While I'm for a usable trunk,
> extending that though to a "releasable trunk" is more committment than
> I'd want.  Maybe I'm reading too much into it but claiming that at any
> given moment the trunk is [apache] release quality is bold.

Ok, probably the wording is too strong.

>>Furthremore, these branches should merge whenever possible between them
>>in a single branch so that they can be coded together, and get merged
>>with the trunk only when all developer-known bugs are fixed.
> 
> I understand that there will inevitably be dependencies between
> branches but I don't care for merging branches into a single branch
> (btw, wouldn't that ultimately become the defacto dev trunk?).

There should not be dependencies between branches. If there is, then it 
should merge in a single branch.

>>This will also make it easier for us to release often, and to learn to
>>make smaller reversible changes rather than big ones that are hard to
>>understand by other developers and users.
>>
>>Let me know what you think.
> 
> I guess the summary is that this sounds like an "Always-Branch" system
> as opposed to the more pragmatic "Branch-When-Needed system" and that
> seems overly rigid for little return.  In other words, I doubt that a
> lot of folks are able to run a trunk in a production environment and
> so burdening yourselves with the overhead of maintaining a trunk in a
> "releasable state" for what would amount to a handful of folks that
> could use it (and likely already have svn loaded anyway) doesn't seem
> worth it.

I am one of those, and I think that most Forrest developers are. If we 
have at least a couple of others willing to use it, we're set.

I have omitted another thing though, that I would like to release 
Forrest *with* SVN stuff, so that patches can always be easy to make and 
to send.

As for the difficulty of maintaining a "releaseable" trunk, see my next 
reply. Thanks for your mail, it helps :-)

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: Project participation and hackability (was: [VOTE] merge locationmap branch with trunk)

[Tim Williams <wi...@gmail.com>]

Since this is about project process, hopefully by my opinions I'm not
violating some unspoken pmc-only line here...

On 6/25/05, Nicola Ken Barozzi <ni...@apache.org> wrote:
> 
> The discussion that has sparked following the request to merge
> incomplete branches in the trunk, along with Tim's comments, gives me
> the opportunity to discuss about how we could manage code change.
> 
> The goal is to increase developer participation and involvment in the
> Forrest Project, by reducing the barrier to entry.

<related>
As one whose recently climbed that barrier, I'd suggest that the
largest barrier of entry to forrest development is it's own cocoon
foundations.  While patches, trunks, and branches are common, sitemaps
and other cocooon concepts take a lot of learning (== time
investment==barrier).  Of course, I could just be the slow one of the
crowd too.  I suspect I'm not the only one that looked at forrest and
had the initial question, "where's the code?"
</related>

...
> 
> Imagine that all cutting-edge users can use the trunk in production. A
> patch is just a couple of actions away. And after incorporation, the
> check is instantaneous, and on a *real* test, as it actually get used.

I may be very well be in a unique situation but I can't imagine many
folks are able to run a trunk on a live production machine?  What
about the CM baggage?  If I were a client of that *real* test, I think
I'd be concerned.  If the recent JRE-version related discussion around
release time are any indiciation, this is not necessarily unique.

> This can only work if the trunk is always *usable*, and not only
> _buildable_. This can make our trunk be really bug-free, as there would
> really be a lot of eyes looking at the code.

I said before that I do like a usable trunk (i.e. buildable + runnable
with no hoop jumping).

> I would thus propose that the trunk be always *releaseable* at all
> times, and that all new functionality that interferes with usage of
> prior features be developed on separate branches.

This, however, is quite a committment.  While I'm for a usable trunk,
extending that though to a "releasable trunk" is more committment than
I'd want.  Maybe I'm reading too much into it but claiming that at any
given moment the trunk is [apache] release quality is bold.

> Furthremore, these branches should merge whenever possible between them
> in a single branch so that they can be coded together, and get merged
> with the trunk only when all developer-known bugs are fixed.

I understand that there will inevitably be dependencies between
branches but I don't care for merging branches into a single branch
(btw, wouldn't that ultimately become the defacto dev trunk?).  I hate
to keep bringing this up but in the current locationmap branch, we
have locationmap functionality==trunkable and
views==just-a-hair-shy-of-trunkable; the result is that it's difficult
to merge lcoationmap now even thought it's mature enough to be merged.
 Granted the hurdles we're facing there are trivial but it's a useful
example.  The point is that if more than one functional components
progress on independent paths towards maturity yet exist in the same
branch, then there would be a dificult time getting the most mature
functionality out the door independent of the others.  For those
inevitable dependencies, perhaps there's an idea of a branch of a
branch given that svn branch is but a copy?

> This will also make it easier for us to release often, and to learn to
> make smaller reversible changes rather than big ones that are hard to
> understand by other developers and users.
> 
> Let me know what you think.

I guess the summary is that this sounds like an "Always-Branch" system
as opposed to the more pragmatic "Branch-When-Needed system" and that
seems overly rigid for little return.  In other words, I doubt that a
lot of folks are able to run a trunk in a production environment and
so burdening yourselves with the overhead of maintaining a trunk in a
"releasable state" for what would amount to a handful of folks that
could use it (and likely already have svn loaded anyway) doesn't seem
worth it.

--tim

Re: Project participation and hackability

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

David Crossley wrote:
> Nicola Ken Barozzi wrote:
> 
>>Imagine that all cutting-edge users can use the trunk in production. A 
>>patch is just a couple of actions away. And after incorporation, the 
>>check is instantaneous, and on a *real* test, as it actually get used.
> 
> 
> I like your general drift. We should also have our own continuous
> integration testing by having our own services at forrest.zones.apache.org

+10000

(I cannot devote time to this until after ApacheCon - or at the Hackathon?)

>>This can only work if the trunk is always *usable*, and not only 
>>_buildable_. This can make our trunk be really bug-free, as there would 
>>really be a lot of eyes looking at the code.
>>
>>I would thus propose that the trunk be always *releaseable* at all 
>>times, and that all new functionality that interferes with usage of 
>>prior features be developed on separate branches.
> 
> 
> I hope that you are still talking about the Branch-When-Needed system.
> http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html
> 
> That is the closest to what we have been doing until now.
> 
> However, we are not diligent enough at the test-before-commit phase.
> Forrestbot on the server would assist, but not replace that need.

+100000

we must all do:

cd FORREST_HOME/main/build test

*before* any major commit and forrest.zones must do frequent builds to 
ensure nobody forgot.

> We have also not been branching enough, although we have been
> much better lately.

I'm reviewing the best practices document Tim and David have linked to 
in order to learn when and why we should branch. Perhaps everyone else 
who hasn't read it should do the same.

http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html

> Good stuff. We must document the outcome of this thread.
> There is a deliberate hole at our project guidelines because we 
> did not yet put this effort into deciding a good management.
> http://forrest.apache.org/guidelines.html#code

Yes, please someone document this (menaing I'm afraid I don't have the 
time).

Ross

Re: Project participation and hackability

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

Nicola Ken Barozzi wrote:
> 
> Imagine that all cutting-edge users can use the trunk in production. A 
> patch is just a couple of actions away. And after incorporation, the 
> check is instantaneous, and on a *real* test, as it actually get used.

I like your general drift. We should also have our own continuous
integration testing by having our own services at forrest.zones.apache.org

> This can only work if the trunk is always *usable*, and not only 
> _buildable_. This can make our trunk be really bug-free, as there would 
> really be a lot of eyes looking at the code.
> 
> I would thus propose that the trunk be always *releaseable* at all 
> times, and that all new functionality that interferes with usage of 
> prior features be developed on separate branches.

I hope that you are still talking about the Branch-When-Needed system.
http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html

That is the closest to what we have been doing until now.

However, we are not diligent enough at the test-before-commit phase.
Forrestbot on the server would assist, but not replace that need.

We have also not been branching enough, although we have been
much better lately.

> Furthremore, these branches should merge whenever possible between them 
> in a single branch so that they can be coded together, and get merged 
> with the trunk only when all developer-known bugs are fixed.

> This will also make it easier for us to release often, and to learn to 
> make smaller reversible changes rather than big ones that are hard to 
> understand by other developers and users.

Good stuff. We must document the outcome of this thread.
There is a deliberate hole at our project guidelines because we 
did not yet put this effort into deciding a good management.
http://forrest.apache.org/guidelines.html#code

-David

Project participation and hackability (was: [VOTE] merge locationmap branch with trunk)

[Nicola Ken Barozzi <ni...@apache.org>]

The discussion that has sparked following the request to merge 
incomplete branches in the trunk, along with Tim's comments, gives me 
the opportunity to discuss about how we could manage code change.

The goal is to increase developer participation and involvment in the 
Forrest Project, by reducing the barrier to entry.

I have been thinking about this lately, because I have tried to be 
involved in other projects that I use for work. Some things that help are:

  * open discussions on mailing lists
  * meritrocracy
  * access to source code
  * clear license
  * collaborativness from existing developers
  * others users that can give you a hand
  * decent documentation to get you started
  * decent reference to key points of the system

These are all present in Forrest, but they are not all.
There is another point which I find very important:

                _hackability_

A project should be hackable, so that users can *quickly* tweak the code 
and make patches, changes, enhancements.

To be hackable, it must be:

  - modular

    In this way it can be hacked in small chunks, which are more
    easily undertstandable. Sitemap separation has done something,
    but the locationmap will be a big improvement, separating
    location resolving and transformation processing

  - extensible

    The plugin system is exactly what we need for this, and is
    proving that it's easier to use.

  - have changes give immediate results

    In-place editing that has been done some time back has shown that
    instant results make it much faster and easier to hack.

  - easy buildability

    We provide Ant, so making it build is quite easy I think

Again, we provide all these... but there is one thing left, which is the 
whole purpose of this mail.

Imagine that you have Forrest in production, and that you find a bug. 
Ok, so you look in the code, find it, and fix it. Now what? You have to 
send a patch... so you should :

  1. download Forrest from SVN
  2. see what has changed since the release
  3. do the fix
  4. test the change again
  5. see how the project accepts patches
  6. create the patch and send it
  7. get on the mailing list to see how the process is going
  8. update the svn forrest once the patch is put in
  9. test it again

Do you see something wrong with this?

I do. It's tooooooo long and tedious. In many cases I have resisted 
sending patches for lack of time.

Another example.
I had done some extra classes I wanted to share, and in the process I 
had made some changes to existing classes. But I had used the 
distribution, not the CVS version, so I had to do the above steps again, 
and halfway through I stopped.

"What the heck" - I thought - "too much hassle. If I could just use the 
trunk in production, it would be much easier".

Imagine that all cutting-edge users can use the trunk in production. A 
patch is just a couple of actions away. And after incorporation, the 
check is instantaneous, and on a *real* test, as it actually get used.

This can only work if the trunk is always *usable*, and not only 
_buildable_. This can make our trunk be really bug-free, as there would 
really be a lot of eyes looking at the code.

I would thus propose that the trunk be always *releaseable* at all 
times, and that all new functionality that interferes with usage of 
prior features be developed on separate branches.

Furthremore, these branches should merge whenever possible between them 
in a single branch so that they can be coded together, and get merged 
with the trunk only when all developer-known bugs are fixed.

This will also make it easier for us to release often, and to learn to 
make smaller reversible changes rather than big ones that are hard to 
understand by other developers and users.

Let me know what you think.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: [VOTE] merge locationmap branch with trunk

[Nicola Ken Barozzi <ni...@apache.org>]

I will vote here and explain the reasons in detail on a separate thread.
In essence, the trunk should always be reasonably error-free, and 
releaseable at all times, to make it possible for cutting-edge users to 
actually test it live in production.

Ross Gardler wrote:
> With 0.7 finally out (congratulations everyone by the way, great work).
> 
> I'd like to take a vote on merging the locationmap branch with trunk. 
> The changes over there are:
> 
> Locationmap
> -----------
> 
> This is pretty much functional, but not in any way complete. There are a 
> couple of outstanding patches from Tim Williams that extend 
> functionality (sorry Tim I will apply them very soon, I've been quite 
> distracted by other things lately).
> 
> The locationmap is backward compatible with 0.7, although the error 
> returned for missing documents is currently a little confusing, this 
> should be improved as a matter of urgency.

-1 to merge now

+1 to merge as soon as the patches are applied and the error is not 
confusing any more.

> Views
> -----
> 
> Lots of work has been happening on views over there. These are totally 
> optional as they are whiteboard plugins.

-1 to merge till the problems are ironed out.

+1 to make all work on the views branch.

> Daisy Plugin
> ------------
> 
> This is version 0.2-dev of the daisy plugin. It is a whiteboard plugin 
> and uses the locationmap to determine where to retrieve files. 0.3 will 
> then go on to retrieve the XML flies from the repository rather than 
> retrieve the HTML files from the wiki application.

+1, obviously as soon as the locationmap branch is merged.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: [VOTE] merge locationmap branch with trunk

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

Ross Gardler wrote:
> 
> As far as I am aware there are no changes that will break existing 
> sites. However, you may want to test this before voting (I have not 
> tested this before calling the vote but you can assume I will do so 
> before actually merging).

I didn't test either. It must merge sometime, so sooner rather than later.

Don't forget the trouble that we had merging the recent docs_reorg branch.
Did you move any files in the branch? If so, were there changes made to
them in the trunk since branching? Anyway, you and Tim and probably better
at SVN than me.

-David

Re: [VOTE] merge locationmap branch with trunk

[Ferdinand Soethe <fe...@apache.org>]

Tim Williams wrote:

> I personally like a stable trunk -- builds and runs without
> hoop-jumping.

I think it is critical to keep the hoops required to an absolute
minimum for two simple reasons:

- even well documented hoops take time each time I set up a new
  instance of Forrest (ok, this doesn't apply for this one necessarily)
  for some ad hoc testing thus making such tests more expensive and my
  less likely to do them.

- the more complicated the handling of trunk becomes, the less likely
  we will get entry level users to try a release before it is actually
  released thus reducing the scope of our tests.

So I'd try and look for a good balance.

--
Ferdinand Soethe

Re: [VOTE] merge locationmap branch with trunk

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

Ross Gardler wrote:
> (it seems I called this vote to early, sorry, I should have discussed 
> first - never mind we are discussing now).

Which is why i always try to encourage people to discuss first.
Otherwise we confuse what it is that we are deciding to do.

Anyway, +1 from me to merge the locationmap branch (including
the views functionality).

I don't mind if the trunk gets a little bit broken, as long it
still builds and runs so that other developers can get in a help
to fix it.

-David

Re: [VOTE] merge locationmap branch with trunk

[Ferdinand Soethe <fe...@apache.org>]

Ross Gardler wrote:

> Why do I want to automate it? Because I'd like (meaning it is my itch)
> to have the build target site do things like ask the user for the 
> project name and other config values. Thus the various config files that
> the user needs to edit to get started are already customised for them.
> Some of these questions are different for skins than they are for views
> (skins = what skin? Which search box? where put it? etc., views = which
> default view? which CSS? etc.)

> Now look what you made me do, I almost created this already, I may as
> well copy it into the locationmap branch now. What do you think?

I think this wizzard is great and will be very helpful when setting up
a new Forrest. But please keep it optional. I'd hate to
have to click myself through a million of defaults.

> Someone mentioned that a while back and I played around with using
> ant's input and replaceregexp but I later removed it because it's a
> pain if you just want to quickly seed a new site for testing.  The
> lesson learned is that if it's interactive it should also have a
> non-interactive mode too -- which I didn't do.  I like the idea of the
> questions, file locations, and regexp's to the properties where the
> answers should go in the files being defined in a "module" outside of
> forrest.build.xml so that the interrogation could be customized.

Best way to do this in my view would be to have an automated mode that
uses the default values for all your questions and does not ask any
questions (keeps the automated and manual modes very much in sync)
with an alternative input from a file.

--
Ferdinand Soethe

Re: Using local plugins (Re: [VOTE] merge locationmap branch with trunk)

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

Ferdinand Soethe wrote:
> Ross Gardler wrote:
> 
> 
>>Furthermore, in my work on versioned plugins for the 0.7 release I took
>>us nearly all the way to having plugins used from the plugins directory
>>if they are present there. That would remove the need for a download or
>>a local-deploy for people using the src version of Forrest.
> 
> 
> I very much like that. What means very nearly all the way? What is
> required to complete that?

Well, it is easy, but it is hard ;-)

There are also two stages to the implementation:

Stage 1 - Install from src
--------------------------

The easy part is:

add a new condition to the plugin download code that detects when the 
src files are available and does a 'local-deploy' in preference to 
downloading the unversioned plugins (versioned plugins should always be 
downloaded). This is all done in main/targets/plugins.xml

The hard part is:

the versioned download stuff in main/targets/plugins.xml is in need of 
refactoring, it is quite complex right now because of all the 
conditional behaviour, Ant is not a programming language and it shows in 
that file. I have created an issue to convert it to an Ant task.

Stage 2 - Use in-place
----------------------

Change the plugin mounting code to mount the plugins from the src directory.

---

Both stages can be done without the refactoring, it shouldn't add too 
much additional complexity since the extra condition tests would be 
added to existing ones. However, I don't want us to loose sight of the 
refactoring that is needed.

Speaking personally, I don't have the time to do this right now (should 
do after ApacheCon), however, it is something that is very important. If 
someone wants to tackle it I will be sure to help out with any questions 
they have.

Ross

Using local plugins (Re: [VOTE] merge locationmap branch with trunk)

[Ferdinand Soethe <fe...@apache.org>]

Ross Gardler wrote:

> Furthermore, in my work on versioned plugins for the 0.7 release I took
> us nearly all the way to having plugins used from the plugins directory
> if they are present there. That would remove the need for a download or
> a local-deploy for people using the src version of Forrest.

I very much like that. What means very nearly all the way? What is
required to complete that?

--
Ferdinand Soethe

Default skin in views (Re: [VOTE] merge locationmap branch with trunk)

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

Ferdinand Soethe wrote:
> Ross Gardler wrote:
> 
> 
>>Personally, I think the current state of views is good enough for Trunk
>>(if we address the fresh-site issue). I've started to use it for a new
>>project, that's what I usually use as my yardstick. Lets see what others
>>say.
> 
> 
> Playing with the default implementation it looks great. The more
> important question to me is how well our default skin works if and
> when it is availble with views.
> 
> Is it already available to play with?

No. However, if I am following things correctly most of the contracts 
are complete. What needs to be done is:

- skinconf.xml -> default.fv stylesheets
- css to make it look right

Am I on the right line?

Ross

Re: [VOTE] merge locationmap branch with trunk

[Ferdinand Soethe <fe...@apache.org>]

Ross Gardler wrote:

> Personally, I think the current state of views is good enough for Trunk
> (if we address the fresh-site issue). I've started to use it for a new
> project, that's what I usually use as my yardstick. Lets see what others
> say.

Playing with the default implementation it looks great. The more
important question to me is how well our default skin works if and
when it is availble with views.

Is it already available to play with?

--
Ferdinand Soethe

Re: [VOTE] merge locationmap branch with trunk

[Addi <ad...@rocktreesky.com>]

Ferdinand Soethe wrote:

>Ross Gardler wrote:
>
>  
>
>>I hadn't thought of that, but it triggered another requirement in my
>>mind, which happens to provide a solution.
>>    
>>
>
>I might add the need for a simple minimum seed for people who want to
>start a fresh site w/o having to move all our demo junk out of it
>first
>  
>
I love this idea.  Such a pain to go back in and "clean" when all I want 
to do is get to working.

>AND
>
>perhaps some custom targets for common applications such as
>
>- myPersonalForrestHomepage
>- myForrestBusinessSite
>
>with a few prefab pages that can be filled by a novice user.
>
>--
>Ferdinand Soethe
>
>
>
>
>  
>

Re: various seed sites (Was: [VOTE] merge locationmap branch with trunk)

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

David Crossley wrote:
> Ferdinand Soethe wrote:
> 
>>Ross Gardler wrote:
>>
>>
>>>I hadn't thought of that, but it triggered another requirement in my
>>>mind, which happens to provide a solution.
>>
>>I might add the need for a simple minimum seed for people who want to
>>start a fresh site w/o having to move all our demo junk out of it
>>first
>>
>>AND
>>
>>perhaps some custom targets for common applications such as
>>
>>- myPersonalForrestHomepage
>>- myForrestBusinessSite
>>
>>with a few prefab pages that can be filled by a novice user.
> 
> 
> Yes, the ability to have various seed sites should be an important
> feature of our next release. We have talked about it a bit before.
> We should create a Jira issue so that it gets on the roadmap.
> 
> Another requirement from the previous discussion was the ability
> to have a raw site, i.e. strip the license headers from the xdocs
> files and have basically no content.

Yes, I deliberately missed this from this thread because I new what was 
about to come, but could not publically announce it until today. I will 
be posting a separate mail regarding this and other issues in a short while.

Ross

various seed sites (Was: [VOTE] merge locationmap branch with trunk)

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

Ferdinand Soethe wrote:
> Ross Gardler wrote:
> 
> > I hadn't thought of that, but it triggered another requirement in my
> > mind, which happens to provide a solution.
> 
> I might add the need for a simple minimum seed for people who want to
> start a fresh site w/o having to move all our demo junk out of it
> first
> 
> AND
> 
> perhaps some custom targets for common applications such as
> 
> - myPersonalForrestHomepage
> - myForrestBusinessSite
> 
> with a few prefab pages that can be filled by a novice user.

Yes, the ability to have various seed sites should be an important
feature of our next release. We have talked about it a bit before.
We should create a Jira issue so that it gets on the roadmap.

Another requirement from the previous discussion was the ability
to have a raw site, i.e. strip the license headers from the xdocs
files and have basically no content.

-David

Re: [VOTE] merge locationmap branch with trunk

[Ferdinand Soethe <fe...@apache.org>]

Ross Gardler wrote:

> I hadn't thought of that, but it triggered another requirement in my
> mind, which happens to provide a solution.

I might add the need for a simple minimum seed for people who want to
start a fresh site w/o having to move all our demo junk out of it
first

AND

perhaps some custom targets for common applications such as

- myPersonalForrestHomepage
- myForrestBusinessSite

with a few prefab pages that can be filled by a novice user.

--
Ferdinand Soethe

Re: [VOTE] merge locationmap branch with trunk

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

Ross Gardler wrote:
> Tim Williams wrote:
> >
> >I thought I'd read that views weren't going to get deployed until you
> >guys had a chance to review them at ApacheCon?  If they're in fact
> >ready, then that would make things simpler.
> 
> Did we say that? I can't remember. I'd be willing to revisit that 
> decision now that I have played with views a little, and more 
> importantly we have some docs and a sample "skin" that works.

No we did not say that. We just said that there will be a
workshop about Views so that we can understand it better
and help to ensure strong foundations.

We put it into the Whiteboard, just to get past the 0.7 release.

We probably need a separate discussion and vote about whether
to move them out of the Whiteboard and about whether they
should be in the core or as a plugin.

-David

Re: [VOTE] merge locationmap branch with trunk

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

Tim Williams wrote:
> On 6/24/05, Ross Gardler <rg...@apache.org> wrote:
> 

...

>>We do prefer a stable trunk. Your concerns are valid and appropriate.
>>
>>(it seems I called this vote to early, sorry, I should have discussed
>>first - never mind we are discussing now).
> 
> 
> There isn't an issue because of the subject of your vote --
> locationmap's alone would likely be fairly smooth merging.  It's that
> the merging of locationmap has been unnecessarily bound to something
> happening with views that is the problem.  In other words,
> locationmaps is cooked enough to merge by itself.  Is there no way to
> merge just the locationmap stuff while views get more fleshing out?

Personally, I think the current state of views is good enough for Trunk 
(if we address the fresh-site issue). I've started to use it for a new 
project, that's what I usually use as my yardstick. Lets see what others 
say.

> I thought I'd read that views weren't going to get deployed until you
> guys had a chance to review them at ApacheCon?  If they're in fact
> ready, then that would make things simpler.

Did we say that? I can't remember. I'd be willing to revisit that 
decision now that I have played with views a little, and more 
importantly we have some docs and a sample "skin" that works.

>>I'd like (meaning it is my itch)
>>to have the build target site do things like ask the user for the
>>project name and other config values. Thus the various config files that
>>the user needs to edit to get started are already customised for them.
>>Some of these questions are different for skins than they are for views
>>(skins = what skin? Which search box? where put it? etc., views = which
>>default view? which CSS? etc.)

...

> Someone mentioned that a while back and I played around with using
> ant's input and replaceregexp but I later removed it because it's a
> pain if you just want to quickly seed a new site for testing.  
> The
> lesson learned is that if it's interactive it should also have a
> non-interactive mode too -- which I didn't do.  

I hadn't thought of that, but it triggered another requirement in my 
mind, which happens to provide a solution.

We will need a seeedTestSite target with no user interaction because 
"./build test" seeds a new site and builds it as part of its tests. Devs 
could also use that target for quick tests. Looking even further into 
the future this could form the basis of an automated test suite. 
Something I think is becoming increasingly important for Forrest.

> Unfortunately, based on what I alluded to earlier, I don't like the
> idea of it going in the locationmap branch personally.  I like the
> idea of the lm branch being functionally consistent with its original
> purpose instead of an all-purpose whiteboard.  

Well the reason Thorsten moved views into the branch was that he needed 
the Locationmap code for some of the newer features of views, he new 
there would be a good few months before the branch was merged because we 
were ramping up for the 0.7 release. I wouldn't call it an "all purpose 
whiteboard", if he hadn't gone into the branch he would be in trunk anyway.

> I guess the
> simple targets could be added painlessly enough but the more
> interactive stuff is what I'm referring to.  The targets would ease my
> concern of having to do additional stuff to the trunk to make it work.

Well those targets are the start of the interactive stuff. Lets not over 
design things, lets do it in an incremental style. With that in mind I'm 
going to be leave this thread alone to give folks a chance to catch up, 
we have come a long way in a short time in this thread.

Ross

Re: [VOTE] merge locationmap branch with trunk

[Tim Williams <wi...@gmail.com>]

On 6/24/05, Ross Gardler <rg...@apache.org> wrote:
> Tim Williams wrote:
> > On 6/24/05, Ross Gardler <rg...@apache.org> wrote:
> >
> >>Tim Williams wrote:
> >>
> >>>Obviously, my enthusiastic, [non-binding] +1
> >>>...
> >>>
> >>>
> >>>>Views
> >>>>-----
> >>>>
> >>>>Lots of work has been happening on views over there. These are totally
> >>>>optional as they are whiteboard plugins.
> >>>
> >>>
> >>>I think I'd take out references to Views from the fresh-site prior
> >>>because right now we have to locally-deploy the three view-related
> >>>plugins to make it work and that bit probably isn't desireable on the
> >>>trunk.  The Views are whiteboard but fresh-site requires them in other
> >>>words.
> >>
> >>Good point, although I'm not sure this is a blocker since people working
> >>with SVN head should be willing to jump a few hoops, especially at the
> >>early stage of development. Lets see what everyone thinks about this.
> >
> >
> > I personally like a stable trunk -- builds and runs without
> > hoop-jumping.  If every new component added a couple more hoops to be
> > jumped through they'd add up quick.  Of course if it's a constant set
> > of hoops that can be documented then no problem.    The discussion at
> > the bottom of this page is about branches but I like the rules of the
> > "Branch-When-Needed system" as it relates to this topic.  I don't know
> > what the "forrest approach" is yet.
> > http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html
> 
> We do prefer a stable trunk. Your concerns are valid and appropriate.
> 
> (it seems I called this vote to early, sorry, I should have discussed
> first - never mind we are discussing now).

There isn't an issue because of the subject of your vote --
locationmap's alone would likely be fairly smooth merging.  It's that
the merging of locationmap has been unnecessarily bound to something
happening with views that is the problem.  In other words,
locationmaps is cooked enough to merge by itself.  Is there no way to
merge just the locationmap stuff while views get more fleshing out?

> Of course, if we deploy the views plugins there will be no need to
> manually install them as long as a network connection is present.
> Furthermore, in my work on versioned plugins for the 0.7 release I took
> us nearly all the way to having plugins used from the plugins directory
> if they are present there. That would remove the need for a download or
> a local-deploy for people using the src version of Forrest.

I thought I'd read that views weren't going to get deployed until you
guys had a chance to review them at ApacheCon?  If they're in fact
ready, then that would make things simpler.

> >>Having said that, how about this...
> >>
> >>forrest seed            - (fresh-site site using skins)
> >>forrest seed_skins      - (fresh-site using skins)
> >>forrest seed_views      - (fresh-site using views)
> >
> >
> > I don't care for the idea of created new temporary targets so much,
> > assuming that 0.8 isn't shipping without views.  If 0.8 is planned to
> > ship with views and skins then I do like this more.
> 
> We try very hard to maintain backward compatability, so in my view we
> will not remove skins in 0.8, but we will deprecate them. I would
> actually like to see them moved out to a plugin for 0.8, but we'll have
> to think about the implications of that.
> 
> We also have to consider the fact that many of our users have invested
> in their own skins. We will need to keep the skins functionality until
> such a time as those users decide to convert their skins to views. This
> implies we will keep the seedSkins target too.

Then I like your idea of a more robust forrest seed below.  I didn't
give as much thought to backward compatibility as I should have.

>  > I could have a
>  > narrow view of this but couldn't we just add a couple of commented
>  > "project.required.plugins" lines and let folks uncomment them as they
>  > see fit and have the lowest common denominator as the default
>  > uncommented one?
> 
> We could, but read on...
> 
> >>I think that all we need do for this is change add the views plugins to
> >>the forrest.properties file, is that right?
> >
> >
> > This sounds like what I'm suggesting above but I may very well be
> > missing the point here.
> 
> Yes that is similar to what I meant. I'm just wanting to remove the need
> for the user to edit the file. You see the different targets (seedSkins
> and seedViews) would actually be exactly the same but for the setting of
> the required plugins in forrest.properties. e.g. (in pseudo code, I
> don't have the ANT manual handy):
> 
> <target name="seedSkins">
>    <antCall target="buildSeed>
>      <param name="required.plugins" value="o.a.f.p.o.PDF"/>
> </target>
> 
> <target name="seedViews">
>    <antCall target="buildSeed>
>      <param name="required.plugins"
>        value="o.a.f.p.o.PDF, o.a.f.p.int.Views"/>
>    </antCall>
> </target>
> 
> <target name="buildSeed">
>    <copy src="fresh-site" dest=".">
>      <replace token="required.plugins" value="${required.plugins}"/>
> </target>
> 
> Why do I want to automate it? Because I'd like (meaning it is my itch)
> to have the build target site do things like ask the user for the
> project name and other config values. Thus the various config files that
> the user needs to edit to get started are already customised for them.
> Some of these questions are different for skins than they are for views
> (skins = what skin? Which search box? where put it? etc., views = which
> default view? which CSS? etc.)
> 
> Now look what you made me do, I almost created this already, I may as
> well copy it into the locationmap branch now. What do you think?

Someone mentioned that a while back and I played around with using
ant's input and replaceregexp but I later removed it because it's a
pain if you just want to quickly seed a new site for testing.  The
lesson learned is that if it's interactive it should also have a
non-interactive mode too -- which I didn't do.  I like the idea of the
questions, file locations, and regexp's to the properties where the
answers should go in the files being defined in a "module" outside of
forrest.build.xml so that the interrogation could be customized.

Unfortunately, based on what I alluded to earlier, I don't like the
idea of it going in the locationmap branch personally.  I like the
idea of the lm branch being functionally consistent with its original
purpose instead of an all-purpose whiteboard.  That way when its
mature enough for merging [like lm is now i think], we get the
functionality without having to worry about whether other functional
components (e.g., views, seeding) need extra cooking.  I guess the
simple targets could be added painlessly enough but the more
interactive stuff is what I'm referring to.  The targets would ease my
concern of having to do additional stuff to the trunk to make it work.

--tim

Re: [VOTE] merge locationmap branch with trunk

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

Tim Williams wrote:
> On 6/24/05, Ross Gardler <rg...@apache.org> wrote:
> 
>>Tim Williams wrote:
>>
>>>Obviously, my enthusiastic, [non-binding] +1
>>>...
>>>
>>>
>>>>Views
>>>>-----
>>>>
>>>>Lots of work has been happening on views over there. These are totally
>>>>optional as they are whiteboard plugins.
>>>
>>>
>>>I think I'd take out references to Views from the fresh-site prior
>>>because right now we have to locally-deploy the three view-related
>>>plugins to make it work and that bit probably isn't desireable on the
>>>trunk.  The Views are whiteboard but fresh-site requires them in other
>>>words.
>>
>>Good point, although I'm not sure this is a blocker since people working
>>with SVN head should be willing to jump a few hoops, especially at the
>>early stage of development. Lets see what everyone thinks about this.
> 
> 
> I personally like a stable trunk -- builds and runs without
> hoop-jumping.  If every new component added a couple more hoops to be
> jumped through they'd add up quick.  Of course if it's a constant set
> of hoops that can be documented then no problem.    The discussion at
> the bottom of this page is about branches but I like the rules of the
> "Branch-When-Needed system" as it relates to this topic.  I don't know
> what the "forrest approach" is yet.
> http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html

We do prefer a stable trunk. Your concerns are valid and appropriate.

(it seems I called this vote to early, sorry, I should have discussed 
first - never mind we are discussing now).

Of course, if we deploy the views plugins there will be no need to 
manually install them as long as a network connection is present. 
Furthermore, in my work on versioned plugins for the 0.7 release I took 
us nearly all the way to having plugins used from the plugins directory 
if they are present there. That would remove the need for a download or 
a local-deploy for people using the src version of Forrest.

>>Having said that, how about this...
>>
>>forrest seed            - (fresh-site site using skins)
>>forrest seed_skins      - (fresh-site using skins)
>>forrest seed_views      - (fresh-site using views)
> 
> 
> I don't care for the idea of created new temporary targets so much,
> assuming that 0.8 isn't shipping without views.  If 0.8 is planned to
> ship with views and skins then I do like this more.  

We try very hard to maintain backward compatability, so in my view we 
will not remove skins in 0.8, but we will deprecate them. I would 
actually like to see them moved out to a plugin for 0.8, but we'll have 
to think about the implications of that.

We also have to consider the fact that many of our users have invested 
in their own skins. We will need to keep the skins functionality until 
such a time as those users decide to convert their skins to views. This 
implies we will keep the seedSkins target too.

 > I could have a
 > narrow view of this but couldn't we just add a couple of commented
 > "project.required.plugins" lines and let folks uncomment them as they
 > see fit and have the lowest common denominator as the default
 > uncommented one?

We could, but read on...

>>I think that all we need do for this is change add the views plugins to
>>the forrest.properties file, is that right?
> 
> 
> This sounds like what I'm suggesting above but I may very well be
> missing the point here.

Yes that is similar to what I meant. I'm just wanting to remove the need 
for the user to edit the file. You see the different targets (seedSkins 
and seedViews) would actually be exactly the same but for the setting of 
the required plugins in forrest.properties. e.g. (in pseudo code, I 
don't have the ANT manual handy):

<target name="seedSkins">
   <antCall target="buildSeed>
     <param name="required.plugins" value="o.a.f.p.o.PDF"/>
</target>

<target name="seedViews">
   <antCall target="buildSeed>
     <param name="required.plugins"
       value="o.a.f.p.o.PDF, o.a.f.p.int.Views"/>
   </antCall>
</target>

<target name="buildSeed">
   <copy src="fresh-site" dest=".">
     <replace token="required.plugins" value="${required.plugins}"/>
</target>

Why do I want to automate it? Because I'd like (meaning it is my itch) 
to have the build target site do things like ask the user for the 
project name and other config values. Thus the various config files that 
the user needs to edit to get started are already customised for them. 
Some of these questions are different for skins than they are for views 
(skins = what skin? Which search box? where put it? etc., views = which 
default view? which CSS? etc.)

Now look what you made me do, I almost created this already, I may as 
well copy it into the locationmap branch now. What do you think?

Ross

Re: [VOTE] merge locationmap branch with trunk

[Tim Williams <wi...@gmail.com>]

On 6/24/05, Ross Gardler <rg...@apache.org> wrote:
> Tim Williams wrote:
> > Obviously, my enthusiastic, [non-binding] +1
> > ...
> >
> >>Views
> >>-----
> >>
> >>Lots of work has been happening on views over there. These are totally
> >>optional as they are whiteboard plugins.
> >
> >
> > I think I'd take out references to Views from the fresh-site prior
> > because right now we have to locally-deploy the three view-related
> > plugins to make it work and that bit probably isn't desireable on the
> > trunk.  The Views are whiteboard but fresh-site requires them in other
> > words.
> 
> Good point, although I'm not sure this is a blocker since people working
> with SVN head should be willing to jump a few hoops, especially at the
> early stage of development. Lets see what everyone thinks about this.

I personally like a stable trunk -- builds and runs without
hoop-jumping.  If every new component added a couple more hoops to be
jumped through they'd add up quick.  Of course if it's a constant set
of hoops that can be documented then no problem.    The discussion at
the bottom of this page is about branches but I like the rules of the
"Branch-When-Needed system" as it relates to this topic.  I don't know
what the "forrest approach" is yet.
http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html

> Having said that, how about this...
> 
> forrest seed            - (fresh-site site using skins)
> forrest seed_skins      - (fresh-site using skins)
> forrest seed_views      - (fresh-site using views)

I don't care for the idea of created new temporary targets so much,
assuming that 0.8 isn't shipping without views.  If 0.8 is planned to
ship with views and skins then I do like this more.  I could have a
narrow view of this but couldn't we just add a couple of commented
"project.required.plugins" lines and let folks uncomment them as they
see fit and have the lowest common denominator as the default
uncommented one?

> When we move the views plugins out of whiteboard we could change the
> default behaviour of the seed and demoSite targets to use views.

For seed I agree, I'm not familiar with the demoSite target yet.  I
wish views would ultimately end up as core forrest instead of a plugin
though personally -- making much of this ultimately a moot point.

> I think that all we need do for this is change add the views plugins to
> the forrest.properties file, is that right?

This sounds like what I'm suggesting above but I may very well be
missing the point here.

--tim

Re: [VOTE] merge locationmap branch with trunk

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

Tim Williams wrote:
> Obviously, my enthusiastic, [non-binding] +1
> ...
> 
>>Views
>>-----
>>
>>Lots of work has been happening on views over there. These are totally
>>optional as they are whiteboard plugins.
> 
> 
> I think I'd take out references to Views from the fresh-site prior
> because right now we have to locally-deploy the three view-related
> plugins to make it work and that bit probably isn't desireable on the
> trunk.  The Views are whiteboard but fresh-site requires them in other
> words.

Good point, although I'm not sure this is a blocker since people working 
with SVN head should be willing to jump a few hoops, especially at the 
early stage of development. Lets see what everyone thinks about this.

Having said that, how about this...

forrest seed		- (fresh-site site using skins)
forrest seed_skins 	- (fresh-site using skins)
forrest seed_views	- (fresh-site using views)

When we move the views plugins out of whiteboard we could change the 
default behaviour of the seed and demoSite targets to use views.

I think that all we need do for this is change add the views plugins to 
the forrest.properties file, is that right?

Ross

Re: [VOTE] merge locationmap branch with trunk

[Tim Williams <wi...@gmail.com>]

Obviously, my enthusiastic, [non-binding] +1
...
> Views
> -----
> 
> Lots of work has been happening on views over there. These are totally
> optional as they are whiteboard plugins.

I think I'd take out references to Views from the fresh-site prior
because right now we have to locally-deploy the three view-related
plugins to make it work and that bit probably isn't desireable on the
trunk.  The Views are whiteboard but fresh-site requires them in other
words.

--tim