You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Thorsten Scherler <th...@apache.org> on 2006/03/22 02:03:10 UTC
[RT] structurer location and resource types (was Re:
[announcement] DOCO prototype in forrest and lenya rep)
El mar, 21-03-2006 a las 10:53 +0100, Thorsten Scherler escribió:
...
> - make dispatcher aware of lenya resource types (I once added a resource
> type action to the dispatcher lm but actually we need a different one
> for lenya, since it keeps this information in a meta file). That means
> we need to extend the dispatcher with meta data lookups. That makes it
> possible to integrate different resource types (not only the xdocs based
> ones). Forrest will then be able to easiely bypass its internal format
> by looking up which structurer to use for the certain resource type.
The dispatcher is designed to be not document centric in its url
mappings.
Meaning something like index.fv:
<forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0">
<forrest:view type="html" hooksXpath="/html/body">
<forrest:property name="branding-css-links-input">
<css url="common.css"/>
</forrest:property>
<forrest:hook name="horizon">
<forrest:contract name="genericMarkup">
<forrest:property name="genericMarkup">
<h1>Welcome, <a href="/start.html">start</a></h1>
</forrest:property>
</forrest:contract>
</forrest:hook>
</forrest:view>
</forrest:views>
does not need a index.xml, nor any other file (besides the css) but
returns perfect html markup. Till now we store it in the xdocs dir.
However lately I noted that keeping the structurer definitions within
the xdocs dir is starting to get real messy.
Remember [branding-theme-profiler contract]
El jue, 16-03-2006 a las 11:57 +0100, Cyriaque Dupoirieux escribió:
>
> I think we have two improvements to do :
>
> * first I tried to call custo.dispatcher.css in order to have a
> unique customised css instead of getRequest.dispatcher.css
> (which
> generates in my case several times the same file exactly)
> o This does not work, the custo.dispatcher.css is empty (but
> it's what I was expected ;-) )
The idea is to define one structurer for the "unique customised css".
Normally you would now create a path like {xdocs}/themes/css/profiler.fv
where you define the <forrest:view type="css"/> with the profiler
contract.
Back in v3 I started to use the term internal structurer
http://svn.apache.org/viewcvs.cgi/forrest/trunk/main/template-sites/v3/src/documentation/content/xdocs/title-to-xhtml2.fv?rev=357566&view=log
and placed them in the xdocs dir.
http://svn.apache.org/viewcvs.cgi?rev=357581&view=rev
I needed to define 2 structurer and 2 different contracts
* internal
1) xdocs/abstract-to-xhtml2.fv which is producing xhtml2 as new internal
format with
2) themes/common/xhtml2/abstract.ft
* output
1) common.fv which is producing xhtml using
2) xhtml2-content-abstract.ft
IMO this internal structurer definition do not belong into the {xdocs}
dir.
Resource types specific structurer have to be stored in a different
folder then the xdocs dir as well.
IMO it makes sense to move them out of the xdocs dir and have something
like
structurer/
|-- internal
|-- resource-types
`-- url
To solve FOR-621 with http://forrest.apache.org/docs_0_80/cap.html is
not enough.
"SourceTypeAction assigns a "type" (a string) to an XML file. This is
done based on information occuring in the header of the XML file, up to
the document (root) element."
This solution works perfectly for xml files but there are so many
non-xml files and formats that can mean a different source type and
needs a different structurer.
We need a counterpart of the SourceTypeAction for non-xml formats and
keeping such information in meta data seems the most logical way.
wdyt?
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
RE: active committers (Was: [RT] structurer location and resource types)
Posted by "Gav...." <br...@brightontown.com.au>.
-----Original Message-----
From: Ross Gardler [mailto:rgardler@apache.org]
Sent: Monday, 27 March 2006 4:51 PM
To: dev@forrest.apache.org
Subject: Re: active committers (Was: [RT] structurer location and resource
types)
Tim Williams wrote:
> On 3/24/06, David Crossley <cr...@apache.org> wrote:
>
...
> To keep it objective, we should add some criteria (see below).
...
> 1) Add to the "who" page that folks listed as "Active Committers" are
> those committers who have contributed (code, docs, community) in the
> last 12 months. They are automatically moved to the "Inactive
> Committers" list based on that criteria. They are, however, welcome
> to return to active duty at any time and should reannounce themselves
> by committing a change listing them as active.
>
> 2) Whoever cares about this should periodically review contributions
> and under the same lazy approval of every other code change [and based
> on the 12 month rule], should change/committ who.xml - the committer
> in question will correct you if you're wrong.
I've not checked our existing guidelines, but assuming there are none that
cover this yet...
+1
Ross
Sounds good to me.
+1
Gav...
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.3.2/293 - Release Date: 26/03/2006
Re: active committers (Was: [RT] structurer location and resource
types)
Posted by Ross Gardler <rg...@apache.org>.
Tim Williams wrote:
> On 3/24/06, David Crossley <cr...@apache.org> wrote:
>
...
> To keep it objective, we should add some criteria (see below).
...
> 1) Add to the "who" page that folks listed as "Active Committers" are
> those committers who have contributed (code, docs, community) in the
> last 12 months. They are automatically moved to the "Inactive
> Committers" list based on that criteria. They are, however, welcome
> to return to active duty at any time and should reannounce themselves
> by committing a change listing them as active.
>
> 2) Whoever cares about this should periodically review contributions
> and under the same lazy approval of every other code change [and based
> on the 12 month rule], should change/committ who.xml - the committer
> in question will correct you if you're wrong.
I've not checked our existing guidelines, but assuming there are none
that cover this yet...
+1
Ross
Re: active committers (Was: [RT] structurer location and resource types)
Posted by Tim Williams <wi...@gmail.com>.
On 3/24/06, David Crossley <cr...@apache.org> wrote:
> David Crossley wrote:
> > Ross Gardler wrote:
> > > Thorsten Scherler wrote:
> > > >
> > > >Yes and I wish that our who.html would reflect the reality of active
> > > >committer and not listing people as active that have not done a single
> > > >commit/mail since years.
My initial reaction to this is 'who cares?' I only see one person
listed that fit your description. If this is your itch you should
feel free to scratch it under a lazy-approval.
> > > You are a committer, you know what to do. Of course, I should also lend
> > > a hand, as should everyone else, but we all do what we can and nobody
> > > else is airing this complaint. The buck stops with you I'm afraid.
> >
> > Anyone on the PMC can review the activity (remember
> > that email discussion counts) and suggest to those
> > committers that we vary who.html
To keep it objective, we should add some criteria (see below).
> > Otherwise people can see the svn@ mailing list
> > archives and the changes.html (which i try to
> > keep published often). Perhaps we should link to
> > those from the bottom of who.html page.
I reckon if this was a strong enough itch for someone then it would be
easy enough to adapt the Developer Activity Report from maven for our
purposes. Of course, that would only give one perspective of all of
the "contributions" we consider valueable.
> How about adding a section called
> "Occasionally Active Committers" or some such?
-1, too subjective. I think we can do two things that'll fairly
unambiguously clear things up.
1) Add to the "who" page that folks listed as "Active Committers" are
those committers who have contributed (code, docs, community) in the
last 12 months. They are automatically moved to the "Inactive
Committers" list based on that criteria. They are, however, welcome
to return to active duty at any time and should reannounce themselves
by committing a change listing them as active.
2) Whoever cares about this should periodically review contributions
and under the same lazy approval of every other code change [and based
on the 12 month rule], should change/committ who.xml - the committer
in question will correct you if you're wrong.
--tim
active committers (Was: [RT] structurer location and resource types)
Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
> > Thorsten Scherler wrote:
> > >
> > >Yes and I wish that our who.html would reflect the reality of active
> > >committer and not listing people as active that have not done a single
> > >commit/mail since years.
> >
> > You are a committer, you know what to do. Of course, I should also lend
> > a hand, as should everyone else, but we all do what we can and nobody
> > else is airing this complaint. The buck stops with you I'm afraid.
>
> Anyone on the PMC can review the activity (remember
> that email discussion counts) and suggest to those
> committers that we vary who.html
>
> Otherwise people can see the svn@ mailing list
> archives and the changes.html (which i try to
> keep published often). Perhaps we should link to
> those from the bottom of who.html page.
How about adding a section called
"Occasionally Active Committers" or some such?
-David
Re: [RT] structurer location and resource types
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> Thorsten Scherler wrote:
> >David Crossley escribi??:
> >
> >>Please don't take my comments below the wrong way.
> >>I seek the best for the project.
> >>
> >>I know that this is a Random Thought thread but
> >>there seem to be some design and direction things
> >>which should break out into separate discussions.
> >>
> >>Thorsten Scherler wrote:
> [snip]
> >>>Actually I am thinking it would make sense to make the dispatcher a
> >>>project on its own and support different frameworks, like e.g. Struts.
> >>>Maybe starting as the first forrest subproject which offers different
> >>>contracts/structurer for e.g. Lenya, forrest, cocoon, struts, ... as
> >>>plugins, modules, ....
> >>
> >>I don't think that this project is big enough
> >>to support sub-projects. We are barely a functioning
> >>community at the moment. The number of truly active
> >>developers is very small.
See below as to why i made this comment.
> >Yes and I wish that our who.html would reflect the reality of active
> >committer and not listing people as active that have not done a single
> >commit/mail since years.
>
> You are a committer, you know what to do. Of course, I should also lend
> a hand, as should everyone else, but we all do what we can and nobody
> else is airing this complaint. The buck stops with you I'm afraid.
Anyone on the PMC can review the activity (remember
that email discussion counts) and suggest to those
committers that we vary who.html
Otherwise people can see the svn@ mailing list
archives and the changes.html (which i try to
keep published often). Perhaps we should link to
those from the bottom of who.html page.
> >Anyway, the reality in this project is that the dispatcher has become a
> >subproject of forrest. Further the dispatcher does not focus to support
> >forrest only, I reviewed the dispatcher code and testing ATM to use it
> >in the cocoon samples and it works quite nicely.
>
> I do not want to comment on this without understanding exactly what you
> mean by "a subproject", can you write a proposal covering design,
> benefits to the Forrest project and community and benefits to the ASF?
>
> Don't assume these things are obvious. They are not to most of us, at
> least to me.
I will wait too. However there is one thing that
i should say now. The reason for my comment above.
Running a sub-project will take effort and potentially
dilute the existing community. It will have separate
mailing lists, repositories, etc. It will also have
separate concerns and release cycles.
At the moment there seems to be mainly me attending
to the project management level and to the documentation
maintenance and publishing process. I am too small to split.
I don't know how to handle this. Not saying that
it is a bad idea.
> As project we do not have any guidelines for proposing subprojects.
> Perhaps we can use the incubator model for proposals. This way, if
> Forrest does not feel it is the right thing to do you will be well on
> your way to creating a proposal for the incubator, you can use this
> initial draft to find a mentor and a champion.
>
> NOTE
>
> I am not suggesting that I support the idea of a subproject or incubator
> project. I'm saying I do not understand why you think this is a benefit
> to everyone, without that understanding I can have no opinion.
>
> ...
-David
Re: [RT] structurer location and resource types
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> El vie, 24-03-2006 a las 22:11 +1100, David Crossley escribió:
>
>>Please don't take my comments below the wrong way.
>>I seek the best for the project.
>>
>>I know that this is a Random Thought thread but
>>there seem to be some design and direction things
>>which should break out into separate discussions.
>>
>>Thorsten Scherler wrote:
>>
>>>Ross Gardler escribi??:
>>>
>>>>Thorsten Scherler wrote:
>>>>
>>>>>Thorsten Scherler escribi??:
>>>>
>>>>...
>>>>
>>>>
...
> The dispatcher can be used and since 2 month we could have released the
> dispatcher from the whiteboard (but I reckon if I am not starting this,
> the dispatcher will remain forever in the whiteboard - no offense).
Then put it to the vote, nobody is blocking this move. In fact I (and
possibly others) have suggested it many times, each time it is *you*
that has blocked becuase you wanted to complete "this" or "that" first -
it is all in the archives.
> BTW we did not even start talking about releasing 0.8.
We have outlined (and agreed) what needs to be completed. There is a
Jira roadmap for it.
>>>That leads to the need to extract as well the lm from forrest core and
>>>to make it to a component on its own (maybe to store the lm in a plugin
>>>makes the most sense).
>>
>>Or perhaps a Cocoon block that we maintain.
>
>
> good as gold
>
> +1
Yes, a Cocoon block would be great. Daisy recently started using the
locationmap in an extension to their CMS. If we make the LM a block then
it is possible the Daisy devs (and others?) will start using it more and
contributing to the code.
>>>Actually I am thinking it would make sense to make the dispatcher a
>>>project on its own and support different frameworks, like e.g. Struts.
>>>Maybe starting as the first forrest subproject which offers different
>>>contracts/structurer for e.g. Lenya, forrest, cocoon, struts, ... as
>>>plugins, modules, ....
>>
>>I don't think that this project is big enough
>>to support sub-projects. We are barely a functioning
>>community at the moment. The number of truly active
>>developers is very small.
>
>
> Yes and I wish that our who.html would reflect the reality of active
> committer and not listing people as active that have not done a single
> commit/mail since years.
You are a committer, you know what to do. Of course, I should also lend
a hand, as should everyone else, but we all do what we can and nobody
else is airing this complaint. The buck stops with you I'm afraid.
> Anyway, the reality in this project is that the dispatcher has become a
> subproject of forrest. Further the dispatcher does not focus to support
> forrest only, I reviewed the dispatcher code and testing ATM to use it
> in the cocoon samples and it works quite nicely.
I do not want to comment on this without understanding exactly what you
mean by "a subproject", can you write a proposal covering design,
benefits to the Forrest project and community and benefits to the ASF?
Don't assume these things are obvious. They are not to most of us, at
least to me.
As project we do not have any guidelines for proposing subprojects.
Perhaps we can use the incubator model for proposals. This way, if
Forrest does not feel it is the right thing to do you will be well on
your way to creating a proposal for the incubator, you can use this
initial draft to find a mentor and a champion.
NOTE
I am not suggesting that I support the idea of a subproject or incubator
project. I'm saying I do not understand why you think this is a benefit
to everyone, without that understanding I can have no opinion.
...
>>I know we said that for the upcoming 0.8 release
>>that skins will still be the default. Is that what
>>you are referring to?
>
>
> I think many committers/dev/user are more committed to skins then to the
> dispatcher and this can be seen in the mail archives. That is perfectly
> ok, if those committers are willing to support skins in the future.
Committers - this is simply not true. There are three active committers
working on the Dispatcher and the rest of us have provided oversight,
feedback and comment.
Devs - again not true, our most active dev (not currently a committer)
spends lots of time trying to understand the dispatcher
Most active devs have creat at least one sites using views, then V2 then
V3 in order to be able to provide feedback to you with respect to your
approaches. This really should be enough for any Open Source Community.
Speaking as a commercial user of Forrest (not someone who is here for
fun, at least not all the time), I cannot adopt the dispatcher in client
sites since it will increase the costs of their projects. I *want* to,
there are features I really need, but I cannot, it is simply not a good
business decision at this time (see below).
Users - true, speaking purely for myself as a user ...
I am currently more committed to skins because the few sites I have
using the dispatcher take up far too many person hours to maintain. This
is because of a lack of design in the original code, resulting in
numerous versions of the code base. This is made worse by a lack of
backward compatability between each "minor" change.
Sure, they are whiteboard components and to an extent this is to be
expected, but only devs will put up with this. Until backward
compatability exists do not expect users to adopt code.
In summary, please remember that we all have different motives for being
here. Perhaps your proposal for a subproject can address some of the
advantages to different types of users.
Ross
Re: planning the 0.8 release (Was: [RT] structurer location and resource types)
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> [ snip ]
>
> I see it working like this:
>
> [ snip ]
I am preparing an answer, but it will take some time.
Difficult in email, but that is the way we need to work.
I am doing some Jira cleanup and adding some other
filters to get a handle on the best way to operate.
Not yet convinced.
-David
Re: planning the 0.8 release
Posted by David Crossley <cr...@apache.org>.
Keeping this topic at the top of the list.
http://issues.apache.org/jira/browse/FOR-853
-David
David Crossley wrote:
> Ross Gardler wrote:
> > David Crossley wrote:
> > >Ross Gardler wrote:
> > >>David Crossley wrote:
> > >>>Ross Gardler wrote:
> > >>>>David Crossley wrote:
> > >>>>
> > >>>>>The "roadmap" mixes in all of the plugins issues.
> > >>>>>The so-called "Priority" is a reporter-based priority.
> > >>>>
> > >>>>Does it? I can't check it right now (I'm replying offline) but I'm
> > >>>>pretty sure I moved all of the plugin stuff out of the roadmap for 0.8.
> > >>>>The only references to plugins in there (that I intentionally left) is
> > >>>>to how core handles plugins.
> > >>>
> > >>>Ah, i did not realise that you were doing that.
> > >>>
> > >>>However, as we move more stuff into plugins,
> > >>>what would happen when we have plugins issues
> > >>>that need to be fixed?
> > >>
> > >>That's where you urgency field comes in (which wasn't available when I
> > >>did the 0.8 roadmap).
> > >
> > >That sounds like it would work. So to assess the
> > >state of the upcoming release, we look at the filters
> > >to see Urgency=blocker and Urgency=urgent
> > >(whether they are marked on the roadmap or not).
> > >The remaining issues on the roadmap are "hope-to-fix".
> > >Is that how you see it too?
>
> I didn't, but i was trying to put the current
> discussion into words.
>
> > Pretty similar to how I see it:
> >
> > I have a slight problem with the sentence "whether they are marked on
> > the roadmap or not".
>
> I added that because i was previously under
> the impression that the plugin issues are on
> the roadmap too.
>
> > My understanding of the urgency field was to allow
> > plugins to have blockers that are not blockers to a core release. We
> > therefore need to be able to keep such issues out of the roadmap, but
> > keep them visible. Hence the introduction of urgency.
>
> I had seen it as applying to all issues.
> After lots of thought in the last few days
> i tend to like your suggested method.
>
> So i suppose that Urgency only applies to plugin issues.
> It is a duplication of information and effort to apply
> it to the general issues, since we would not use it there.
>
> Actually i wonder if your techinique of leaving
> plugin issues out of the roadmap removes the need
> for the Urgency field. Could filters [D] and [E]
> use the Priority field instead?
>
> > I see it working like this:
> >
> > Priority indicates priority to that part of the project (core or plugin).
>
> Currently we say that Priority is the "severity" from
> the reporter/user point-of-view, i.e. how it affects them. [A]
> I will change the docs and Jira prompts
>
> > Urgency indicates the likelihood of the community fixing it (as opposed
> > to the reporter).
>
> Yes, community. I don't think that the reporter
> matters in this case.
>
> > So, a blocker for the OOo plugin may only have a low urgency if it is
> > unique to a specific use case for a specific user. On the other hand, a
> > low priority issue may be an indicate of a problem with the design of
> > the plugin system in the core, in which case we are likely to give it a
> > high urgency.
>
> I had trouble coming up with good examples.
> Your second example would probably result in
> creating a new core Issue about fixing the
> plugin system.
>
> Again i am wondering if the Urgency field is
> worth the effort with the new way of managing the
> roadmap.
>
> > So, to establish the state of a core release, look at the 0.8-dev roadmap.
>
> Made a filter for that: [B] FOR-roadmap-dev
>
> While we are here, lets figure out how to progress
> to a release. How is this:
>
> * Each of us visit [C] and add any more core issues
> that we would realistically like to have fixed onto
> the roadmap [B].
>
> * The roadmap is going to be too big (already 40).
> So we review it and move some issues over to Fix-for=0.9
> i.e. put them on the next roadmap rather than send
> them back to the unscheduled basket. Also jiggle some
> Priority values. Need some discussion on each issue.
>
> * Focus on the remaining issues.
>
> * Repeat that process or carefully watch new issues.
> Only put them on 0.8 roadmap if really necessary.
>
> > To establish the state of a plugin release look at the urgency/priority
> > of issues against that plugin.
>
> Yes. Also made two filters to show such issues
> for all plugins:
> [D] FOR-plugins-blocker
> [E] FOR-plugins-urgent
>
> > To find issues that are unscheduled, but should be in the roadmap look
> > at all non-plugin issues sorted by priority/urgency.
>
> Made a filter for that: [C] FOR-unscheduled-not-plugin
>
> > >There were many issues in the "unscheduled" before
> > >you started. Speaking for myself, i don't look
> > >often enough at that filter.
> >
> > I reviewed all issues when creating the roadmap (after discussion). That
> > doesn't mean I didn't miss any, but I did my best ;-)
>
> [A] Forrest issue tracker description
> http://forrest.apache.org/issues.html
> [B] FOR-roadmap-dev
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310820
> [C] FOR-unscheduled-not-plugin
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310822
> [D] FOR-plugins-blocker
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310825
> [E] FOR-plugins-urgent
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310824
>
> Note that some filters don't work well yet because
> we still need to classify the issues.
>
> -David
Re: planning the 0.8 release
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
> >>David Crossley wrote:
> >>>Ross Gardler wrote:
> >>>>David Crossley wrote:
> >>>>
> >>>>>The "roadmap" mixes in all of the plugins issues.
> >>>>>The so-called "Priority" is a reporter-based priority.
> >>>>
> >>>>Does it? I can't check it right now (I'm replying offline) but I'm
> >>>>pretty sure I moved all of the plugin stuff out of the roadmap for 0.8.
> >>>>The only references to plugins in there (that I intentionally left) is
> >>>>to how core handles plugins.
> >>>
> >>>Ah, i did not realise that you were doing that.
> >>>
> >>>However, as we move more stuff into plugins,
> >>>what would happen when we have plugins issues
> >>>that need to be fixed?
> >>
> >>That's where you urgency field comes in (which wasn't available when I
> >>did the 0.8 roadmap).
> >
> >That sounds like it would work. So to assess the
> >state of the upcoming release, we look at the filters
> >to see Urgency=blocker and Urgency=urgent
> >(whether they are marked on the roadmap or not).
> >The remaining issues on the roadmap are "hope-to-fix".
> >Is that how you see it too?
I didn't, but i was trying to put the current
discussion into words.
> Pretty similar to how I see it:
>
> I have a slight problem with the sentence "whether they are marked on
> the roadmap or not".
I added that because i was previously under
the impression that the plugin issues are on
the roadmap too.
> My understanding of the urgency field was to allow
> plugins to have blockers that are not blockers to a core release. We
> therefore need to be able to keep such issues out of the roadmap, but
> keep them visible. Hence the introduction of urgency.
I had seen it as applying to all issues.
After lots of thought in the last few days
i tend to like your suggested method.
So i suppose that Urgency only applies to plugin issues.
It is a duplication of information and effort to apply
it to the general issues, since we would not use it there.
Actually i wonder if your techinique of leaving
plugin issues out of the roadmap removes the need
for the Urgency field. Could filters [D] and [E]
use the Priority field instead?
> I see it working like this:
>
> Priority indicates priority to that part of the project (core or plugin).
Currently we say that Priority is the "severity" from
the reporter/user point-of-view, i.e. how it affects them. [A]
I will change the docs and Jira prompts
> Urgency indicates the likelihood of the community fixing it (as opposed
> to the reporter).
Yes, community. I don't think that the reporter
matters in this case.
> So, a blocker for the OOo plugin may only have a low urgency if it is
> unique to a specific use case for a specific user. On the other hand, a
> low priority issue may be an indicate of a problem with the design of
> the plugin system in the core, in which case we are likely to give it a
> high urgency.
I had trouble coming up with good examples.
Your second example would probably result in
creating a new core Issue about fixing the
plugin system.
Again i am wondering if the Urgency field is
worth the effort with the new way of managing the
roadmap.
> So, to establish the state of a core release, look at the 0.8-dev roadmap.
Made a filter for that: [B] FOR-roadmap-dev
While we are here, lets figure out how to progress
to a release. How is this:
* Each of us visit [C] and add any more core issues
that we would realistically like to have fixed onto
the roadmap [B].
* The roadmap is going to be too big (already 40).
So we review it and move some issues over to Fix-for=0.9
i.e. put them on the next roadmap rather than send
them back to the unscheduled basket. Also jiggle some
Priority values. Need some discussion on each issue.
* Focus on the remaining issues.
* Repeat that process or carefully watch new issues.
Only put them on 0.8 roadmap if really necessary.
> To establish the state of a plugin release look at the urgency/priority
> of issues against that plugin.
Yes. Also made two filters to show such issues
for all plugins:
[D] FOR-plugins-blocker
[E] FOR-plugins-urgent
> To find issues that are unscheduled, but should be in the roadmap look
> at all non-plugin issues sorted by priority/urgency.
Made a filter for that: [C] FOR-unscheduled-not-plugin
> >There were many issues in the "unscheduled" before
> >you started. Speaking for myself, i don't look
> >often enough at that filter.
>
> I reviewed all issues when creating the roadmap (after discussion). That
> doesn't mean I didn't miss any, but I did my best ;-)
[A] Forrest issue tracker description
http://forrest.apache.org/issues.html
[B] FOR-roadmap-dev
http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310820
[C] FOR-unscheduled-not-plugin
http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310822
[D] FOR-plugins-blocker
http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310825
[E] FOR-plugins-urgent
http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310824
Note that some filters don't work well yet because
we still need to classify the issues.
-David
Re: planning the 0.8 release (Was: [RT] structurer location and resource
types)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>David Crossley wrote:
>>
>>>Ross Gardler wrote:
>>>
>>>>David Crossley wrote:
>>>>
>>>>
>>>>>The "roadmap" mixes in all of the plugins issues.
>>>>>The so-called "Priority" is a reporter-based priority.
>>>>
>>>>Does it? I can't check it right now (I'm replying offline) but I'm
>>>>pretty sure I moved all of the plugin stuff out of the roadmap for 0.8.
>>>>The only references to plugins in there (that I intentionally left) is
>>>>to how core handles plugins.
>>>
>>>Ah, i did not realise that you were doing that.
>>>
>>>However, as we move more stuff into plugins,
>>>what would happen when we have plugins issues
>>>that need to be fixed?
>>
>>That's where you urgency field comes in (which wasn't available when I
>>did the 0.8 roadmap).
>
>
> That sounds like it would work. So to assess the
> state of the upcoming release, we look at the filters
> to see Urgency=blocker and Urgency=urgent
> (whether they are marked on the roadmap or not).
> The remaining issues on the roadmap are "hope-to-fix".
> Is that how you see it too?
Pretty similar to how I see it:
I have a slight problem with the sentence "whether they are marked on
the roadmap or not". My understanding of the urgency field was to allow
plugins to have blockers that are not blockers to a core release. We
therefore need to be able to keep such issues out of the roadmap, but
keep them visible. Hence the introduction of urgency.
I see it working like this:
Priority indicates priority to that part of the project (core or plugin).
Urgency indicates the likelihood of the community fixing it (as opposed
to the reporter).
So, a blocker for the OOo plugin may only have a low urgency if it is
unique to a specific use case for a specific user. On the other hand, a
low priority issue may be an indicate of a problem with the design of
the plugin system in the core, in which case we are likely to give it a
high urgency.
So, to establish the state of a core release, look at the 0.8-dev roadmap.
To establish the state of a plugin release look at the urgency/priority
of issues against that plugin.
To find issues that are unscheduled, but should be in the roadmap look
at all non-plugin issues sorted by priority/urgency.
> There were many issues in the "unscheduled" before
> you started. Speaking for myself, i don't look
> often enough at that filter.
I reviewed all issues when creating the roadmap (after discussion). That
doesn't mean I didn't miss any, but I did my best ;-)
Ross
Re: planning the 0.8 release (Was: [RT] structurer location and resource types)
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
> >>David Crossley wrote:
> >>
> >>>The "roadmap" mixes in all of the plugins issues.
> >>>The so-called "Priority" is a reporter-based priority.
> >>
> >>Does it? I can't check it right now (I'm replying offline) but I'm
> >>pretty sure I moved all of the plugin stuff out of the roadmap for 0.8.
> >>The only references to plugins in there (that I intentionally left) is
> >>to how core handles plugins.
> >
> >Ah, i did not realise that you were doing that.
> >
> >However, as we move more stuff into plugins,
> >what would happen when we have plugins issues
> >that need to be fixed?
>
> That's where you urgency field comes in (which wasn't available when I
> did the 0.8 roadmap).
That sounds like it would work. So to assess the
state of the upcoming release, we look at the filters
to see Urgency=blocker and Urgency=urgent
(whether they are marked on the roadmap or not).
The remaining issues on the roadmap are "hope-to-fix".
Is that how you see it too?
> >>>We also need regularly look at the "unscheduled"
> >>>filter and add some to the roadmap. There have
> >>>been many new issues added since you did that
> >>>initial classification.
> >>
> >>I have been watching them carefully and adding those necessary to the 08
> >>roadmap. I may have missed some, i don't claim that this is finished
> >>since it has not been reviewed by the community. But the point is most
> >>of what you say needs to be done has been done. It just needs review. I
> >>have been progressing along this roadmap assuming lazy consensus was in
> >>operation.
It is in operation.
There were many issues in the "unscheduled" before
you started. Speaking for myself, i don't look
often enough at that filter.
> >We agreed that we needed to have the additional
> >field called "Urgency" (see earlier in this thread).
> >You helped to craft the words to explain it and
> >to define the options. See:
> >http://forrest.apache.org/issues.html#urgency
>
> Yes, and as new issues have been coming in I have tried to give them an
> urgency rating, although I am sure some have slipped through my net.
We still need to attend to this "Urgency" rating.
There are not many issues listed so far.
-David
Re: planning the 0.8 release (Was: [RT] structurer location and resource
types)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>David Crossley wrote:
>>
>>>Ross Gardler wrote:
>>>
>>>>David Crossley wrote:
>>
>>...
>>
>>
>>>>http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310000&fixfor=12310040
>>
>>...
>>
>>
>>>The "roadmap" mixes in all of the plugins issues.
>>>The so-called "Priority" is a reporter-based priority.
>>
>>Does it? I can't check it right now (I'm replying offline) but I'm
>>pretty sure I moved all of the plugin stuff out of the roadmap for 0.8.
>>The only references to plugins in there (that I intentionally left) is
>>to how core handles plugins.
>
>
> Ah, i did not realise that you were doing that.
>
> However, as we move more stuff into plugins,
> what would happen when we have plugins issues
> that need to be fixed?
That's where you urgency field comes in (which wasn't available when I
did the 0.8 roadmap).
>>>We also need regularly look at the "unscheduled"
>>>filter and add some to the roadmap. There have
>>>been many new issues added since you did that
>>>initial classification.
>>
>>I have been watching them carefully and adding those necessary to the 08
>>roadmap. I may have missed some, i don't claim that this is finished
>>since it has not been reviewed by the community. But the point is most
>>of what you say needs to be done has been done. It just needs review. I
>>have been progressing along this roadmap assuming lazy consensus was in
>>operation.
>
>
> We agreed that we needed to have the additional
> field called "Urgency" (see earlier in this thread).
> You helped to craft the words to explain it and
> to define the options. See:
> http://forrest.apache.org/issues.html#urgency
Yes, and as new issues have been coming in I have tried to give them an
urgency rating, although I am sure some have slipped through my net.
Ross
Re: planning the 0.8 release (Was: [RT] structurer location and resource types)
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
> >>David Crossley wrote:
>
> ...
>
> >>http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310000&fixfor=12310040
>
> ...
>
> >The "roadmap" mixes in all of the plugins issues.
> >The so-called "Priority" is a reporter-based priority.
>
> Does it? I can't check it right now (I'm replying offline) but I'm
> pretty sure I moved all of the plugin stuff out of the roadmap for 0.8.
> The only references to plugins in there (that I intentionally left) is
> to how core handles plugins.
Ah, i did not realise that you were doing that.
However, as we move more stuff into plugins,
what would happen when we have plugins issues
that need to be fixed?
> >We also need regularly look at the "unscheduled"
> >filter and add some to the roadmap. There have
> >been many new issues added since you did that
> >initial classification.
>
> I have been watching them carefully and adding those necessary to the 08
> roadmap. I may have missed some, i don't claim that this is finished
> since it has not been reviewed by the community. But the point is most
> of what you say needs to be done has been done. It just needs review. I
> have been progressing along this roadmap assuming lazy consensus was in
> operation.
We agreed that we needed to have the additional
field called "Urgency" (see earlier in this thread).
You helped to craft the words to explain it and
to define the options. See:
http://forrest.apache.org/issues.html#urgency
-David
Re: planning the 0.8 release (Was: [RT] structurer location and resource
types)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>David Crossley wrote:
...
>>
>>http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310000&fixfor=12310040
>>
...
>
> The "roadmap" mixes in all of the plugins issues.
> The so-called "Priority" is a reporter-based priority.
Does it? I can't check it right now (I'm replying offline) but I'm
pretty sure I moved all of the plugin stuff out of the roadmap for 0.8.
The only references to plugins in there (that I intentionally left) is
to how core handles plugins.
> We also need regularly look at the "unscheduled"
> filter and add some to the roadmap. There have
> been many new issues added since you did that
> initial classification.
I have been watching them carefully and adding those necessary to the 08
roadmap. I may have missed some, i don't claim that this is finished
since it has not been reviewed by the community. But the point is most
of what you say needs to be done has been done. It just needs review. I
have been progressing along this roadmap assuming lazy consensus was in
operation.
>>>>What are the improvements to Forrest other than dispatcher
>>>>that warrant there being a 0.8 release ?
>>>
>>>Lets make a dotpoint list here in email.
>>
>>For my take on this see the (yawn) 0.8 roadmap. I'm not about to do it
>>all again - others can add/remove as they see fit. I'll re-emerge when
>>the discussion dies down and a vote is called.
>
>
> Apart from a simple list of all issues that have
> been fixed, i don't see any dotpoint list in the
> roadmap that we can use to write the release notes.
I think we interpreted the question differently. You interpreted it as
"what *has* been done" I interpreted it as "what *needs* to be done". If
we put both our answers together we have it well covered ;-)
Ross
Re: planning the 0.8 release (Was: [RT] structurer location and resource types)
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >I am pulling the bits out of this RT that concern the
> >release. Please add more from the other replies.
> >
> >This thread can identify what needs to be done.
> >Out of it we can develop a release plan which
> >defines a realistic target date. Voting on that
> >plan is necessary and has the advantage of drawing
> >attention to getting ready for the release.
> >
> >Gav.... wrote:
> >>Thorsten Scherler wrote:
> >>>David Crossley escribi??:
> >>>
> >>>>I would like us to get moving on solving the
> >>>>general issues for the release, not just the
> >>>>dispatcher ones. We are dragging on too long.
> >>>
> >>>What are the general issues? Why do you think *we* are only focusing on
> >>>dispatcher ones?
> >>
> >>Dispatcher is moving along quickly, and so I guess is receiving a lot of
> >>focus
> >>at the moment, which is good. I do think though that other issues are
> >>taking a
> >>back seat at the moment. I for one have been focusing my attentions on
> >>getting
> >>dispatcher working on my system, trying to find things I could contribute
> >>to it,
> >>this has the impact of me not looking at Jira for other issues that need
> >>attention.
> >
> >Well said Gav. This is what i meant by my comments.
> >
> >None of us are even bothering to categorise the issues
> >in Jira, so that we know what needs to be done for the
> >release. Every ForrestFriday we say that we will do it
> >but we don't.
>
> This is not quite true. We are making good progress on using Jira better.
I know that we are much improved.
> I've put in loads of effort to keep the locationmap work well defined in
> Jira.
Well done. That is one of the important multi-faceted
issues.
> I've also done lots of work on trying to define what will be in
> the 0.8 release (after discussion and agreement on list, but no vote).
Yes you did, thanks. However there is more
such classification needed.
> Similarly, Thorsten has begun to make considerable use of JIRA with the
> work required on Dispatcher.
>
> Many of us are starting to remember to put issue numbers in commit messages.
>
> There is room for improvement, but I think we are certainly going in the
> right direction.
I agree.
> >Attention is being drawn away from the release.
> >It is a natural thing for the exciting new development
> >to cause that. We need to balance that urge with
> >needing to get the release out the door.
>
> Yes, I nearly fell over when someone else committed something on the 0.8
> roadmap today (thanks again).
>
> Having said that, people should be free to work where they need to work,
> my comment above is not intended to point fingers - I've not found much
> time for Forrest code recently ([OT] I do have some cool new plugins
> "coming soon" - most notably an OSCommerce input plugin - really handy
> for printed catalogues - now if only the dispatcher could product PDF... ).
>
> >My comment was meant to say: lets take a breath, pause,
> >tidy up, and get the release out ASAP.
>
> +1, especally to the "tidy up" part. Forrest is getting to be a real
> mess with far too many unfinished parts. See the 0.8 roadmap in Jira, in
> this roadmap I have tried to pull together those lose ends.
>
> >>So lets talk about it, I guess we need to filter Jira for what IS holding
> >>up
> >>a 0.8 release and go through them. Perhaps the next Forrest Friday should
> >>focus on this.
> >
> >Yes. Again. I put a helluva lot of effort in
> >to implement our discussion about adding a
> >new category to jira so that we can classify
> >issues properly and get a rough idea about what
> >is needed for the release:
> >http://forrest.apache.org/issues.html#priority
> >http://forrest.apache.org/issues.html#urgency
> >http://forrest.apache.org/issues.html#filters
>
> How many times can I repeat myself in one mail:
>
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310000&fixfor=12310040
>
> This roadmap was done before the urgency field was added, and I confess
> I have not been through the whole thing again to add this field
> information. I don't actually think there is a need to since I moved all
> of the none core stuff out of the 0.8 release. Plugins can have
> different release cycles (at least they can if we tidy of the versioned
> plugins system - which is in the 0.8 roadmap). The urgency field is only
> really important when plugins are thrown into the mix.
The "roadmap" mixes in all of the plugins issues.
The so-called "Priority" is a reporter-based priority.
We had a huge discussion about this and the outcome was
that the "roadmap" gives us a rough idea, but the new
"urgency" filter would define how we, the project,
see the state of things.
The trouble is that we have not done the next phase
after your classification. We need to assess each
issue that you have put in the roadmap and assign
the Urgency.
We also need regularly look at the "unscheduled"
filter and add some to the roadmap. There have
been many new issues added since you did that
initial classification.
> >>What are the improvements to Forrest other than dispatcher
> >>that warrant there being a 0.8 release ?
> >
> >Lets make a dotpoint list here in email.
>
> For my take on this see the (yawn) 0.8 roadmap. I'm not about to do it
> all again - others can add/remove as they see fit. I'll re-emerge when
> the discussion dies down and a vote is called.
Apart from a simple list of all issues that have
been fixed, i don't see any dotpoint list in the
roadmap that we can use to write the release notes.
As described above, the main incentives are the things that
will go into our release notes. These notes are manually
gleaned from status.xml file with the assistance of
the releaseNotes_0.8-dev.html
> >We could do a 0.7.1 release from the branch.
> >However it would be better to release 0.8 which
> >includes all those fixes and much more.
>
> +1 to a 0.8 release when stuff is done
> -0 to a 0.7.1 release
>
> >>Should Dispatcher, although as you suggest, not part of the 0.8 release
> >>program
> >>and not holding up a 0.8 release, be moved from Whiteboard into
> >>core/plugin at
> >>the same time, now, or after ?
> >
> >Anytime. However it takes someone to research the
> >side-effects, make a proposal, co-ordinate it.
> >
> >My current opinion is that it should happen after
> >the release. Lets explore that topic in a separate
> >thread.
>
> That was the original plan: get 0.8 out, then do the integration work
> for Dispatcher and get 0.9 out. 0.9 would also include the new
> properties system, which is required by the dispatcher.
>
> Of course, if dispatcher remains a plugin, it can be released at any time.
>
> >>What are the incentives for users to upgrade to 0.8 from 0.7 ?
> >
> >See the need for release notes above.
>
> One more time....
>
> and the 0.8 roadmap in Jira ;-)
Yes, that provides the list of all fixed issues.
The svn mailing list provides a list of every change.
The changes.html should list the main changes.
The "importance" attribute should list the important
changes, but see
http://localhost:8888/docs_0_80/releaseNotes_0.8-dev.html
-David
Re: planning the 0.8 release (Was: [RT] structurer location and resource
types)
Posted by Ross Gardler <rg...@apache.org>.
Gav.... wrote:
>
> ----- Original Message ----- From: "Ross Gardler" <rg...@apache.org>
> To: <de...@forrest.apache.org>
>
>>
>>>> What are the improvements to Forrest other than dispatcher
>>>> that warrant there being a 0.8 release ?
>>>
>>>
>>>
>>> Lets make a dotpoint list here in email.
>>
>>
>> For my take on this see the (yawn) 0.8 roadmap. I'm not about to do it
>> all again - others can add/remove as they see fit. I'll re-emerge when
>> the discussion dies down and a vote is called.
>
>
> Sorry, what I meant by that, is what improvements have already been made
> to warrant a 0.8 release.
Yes, you are right. My comment was not intended to discourage you or
anyone else from having a discussion. It was intended to indicate that I
have already made my contribution to that discussion. Please keep up the
great work you are doing in this thread.
What we need to do is *finish* the improvements so we can release. That
is what my roadmap in Jira is intended to help us manage.
> Ok, so there are 41 Issues that need clearing up, then we can release
> 0.8 yes ?
That is my opinion, yes. Others need to look over the list and
add/remove as necessary (after suitable discussion where necessary).
> Looking at the first on the list , FOR-591, this is a Cocoon Issue
> (Cocoon-1574) and they are working on it, however the last comment was
> two months ago now. I have just added a comment to see how they are
> getting on, if no near time frame for resolving it then maybe this will
> have to be put back to a 0.9 release.#
It's a critical issue, can we afford to demote it? I don't think so,
having a memory leak is a pretty major thing in a production environment.
> The next on the list, FOR-713, html-to-document no longer converts to
> XDoc. Was wondering if any conversions have been missed, perhaps
> references to html2document still exist in the processing, they do
> certainly in the docs, I will patch the docs.
No it is a problem with some changes to the XSL that have been made in
this iteration.
> Hmm, thinking about it before I carry on, I really should be adding
> these notes to the issues themselves.
It's often easier to discuss here and link to the thread from JIRA, but
please keep it to one issue per thread.
Ross
Re: planning the 0.8 release (Was: [RT] structurer location and resource types)
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "Ross Gardler" <rg...@apache.org>
To: <de...@forrest.apache.org>
>
>>>What are the improvements to Forrest other than dispatcher
>>>that warrant there being a 0.8 release ?
>>
>>
>> Lets make a dotpoint list here in email.
>
> For my take on this see the (yawn) 0.8 roadmap. I'm not about to do it all
> again - others can add/remove as they see fit. I'll re-emerge when the
> discussion dies down and a vote is called.
Sorry, what I meant by that, is what improvements have already been made
to warrant a 0.8 release.
>
>> We could do a 0.7.1 release from the branch.
>> However it would be better to release 0.8 which
>> includes all those fixes and much more.
>
> +1 to a 0.8 release when stuff is done
> -0 to a 0.7.1 release
I agree with Ross.
>
>>>Should Dispatcher, although as you suggest, not part of the 0.8 release
>>>program
>>>and not holding up a 0.8 release, be moved from Whiteboard into
>>>core/plugin at
>>>the same time, now, or after ?
>>
>>
>> Anytime. However it takes someone to research the
>> side-effects, make a proposal, co-ordinate it.
>>
>> My current opinion is that it should happen after
>> the release. Lets explore that topic in a separate
>> thread.
+1
>
> One more time....
>
> and the 0.8 roadmap in Jira ;-)
>
> Ross
:)
Ok, so there are 41 Issues that need clearing up, then we can release 0.8
yes ?
Looking at the first on the list , FOR-591, this is a Cocoon Issue
(Cocoon-1574) and they are working on it, however the last comment was two
months ago now. I have just added a comment to see how they are getting on,
if no near time frame for resolving it then maybe this will have to be put
back to a 0.9 release.
The next on the list, FOR-713, html-to-document no longer converts to XDoc.
Was wondering if any conversions have been missed, perhaps references to
html2document still exist in the processing, they do certainly in the docs,
I will patch the docs.
Hmm, thinking about it before I carry on, I really should be adding these
notes to the issues themselves.
Will do that later.
Gav...
Re: planning the 0.8 release (Was: [RT] structurer location and resource
types)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> I am pulling the bits out of this RT that concern the
> release. Please add more from the other replies.
>
> This thread can identify what needs to be done.
> Out of it we can develop a release plan which
> defines a realistic target date. Voting on that
> plan is necessary and has the advantage of drawing
> attention to getting ready for the release.
>
> Gav.... wrote:
>
>>Thorsten Scherler wrote:
>>
>>>David Crossley escribi??:
>>>
>>>>Please don't take my comments below the wrong way.
>>>>I seek the best for the project.
>>>>
>>>>I know that this is a Random Thought thread but
>>>>there seem to be some design and direction things
>>>>which should break out into separate discussions.
>
>
> People, please do this for other topics from that RT.
> I am going away from the weekend so cannot do more.
> We need to be able to focus ourselves and refer to
> certain discussion. Otherwise we go in circles.
>
>
>>>>Thorsten Scherler wrote:
>>>>
>>>>>Ross Gardler escribi??:
>>>>>
>>>>>Regarding backward compatible in general for views/dispatcher/... we
>>>>>said that we do not care about it.
>>>>
>>>>Did we decide on a plan for removing those old
>>>>plugins and docs before releasing 0.8?
>>>
>>>No, we have a couple of issues though:
>>>http://issues.apache.org/jira/browse/FOR-798
>>>http://issues.apache.org/jira/browse/FOR-797
>>
>>>It is nearly finished, but help is *very* welcome.
>>
>>If you give me an example of what needs changing I will have a go over the
>>weekend.
>>
>>
>>>>At some stage soon we do need to worry about
>>>>backwards compatibility.
>>>>
>>>>
>>>>I would like us to get moving on solving the
>>>>general issues for the release, not just the
>>>>dispatcher ones. We are dragging on too long.
>>>
>>>What are the general issues? Why do you think *we* are only focusing on
>>>dispatcher ones?
>>
>>Dispatcher is moving along quickly, and so I guess is receiving a lot of
>>focus
>>at the moment, which is good. I do think though that other issues are
>>taking a
>>back seat at the moment. I for one have been focusing my attentions on
>>getting
>>dispatcher working on my system, trying to find things I could contribute
>>to it,
>>this has the impact of me not looking at Jira for other issues that need
>>attention.
>
>
> Well said Gav. This is what i meant by my comments.
>
> None of us are even bothering to categorise the issues
> in Jira, so that we know what needs to be done for the
> release. Every ForrestFriday we say that we will do it
> but we don't.
This is not quite true. We are making good progress on using Jira better.
I've put in loads of effort to keep the locationmap work well defined in
Jira. I've also done lots of work on trying to define what will be in
the 0.8 release (after discussion and agreement on list, but no vote).
Similarly, Thorsten has begun to make considerable use of JIRA with the
work required on Dispatcher.
Many of us are starting to remember to put issue numbers in commit messages.
There is room for improvement, but I think we are certainly going in the
right direction.
> Attention is being drawn away from the release.
> It is a natural thing for the exciting new development
> to cause that. We need to balance that urge with
> needing to get the release out the door.
Yes, I nearly fell over when someone else committed something on the 0.8
roadmap today (thanks again).
Having said that, people should be free to work where they need to work,
my comment above is not intended to point fingers - I've not found much
time for Forrest code recently ([OT] I do have some cool new plugins
"coming soon" - most notably an OSCommerce input plugin - really handy
for printed catalogues - now if only the dispatcher could product PDF... ).
> My comment was meant to say: lets take a breath, pause,
> tidy up, and get the release out ASAP.
+1, especally to the "tidy up" part. Forrest is getting to be a real
mess with far too many unfinished parts. See the 0.8 roadmap in Jira, in
this roadmap I have tried to pull together those lose ends.
>>So lets talk about it, I guess we need to filter Jira for what IS holding up
>>a 0.8 release and go through them. Perhaps the next Forrest Friday should
>>focus on this.
>
>
> Yes. Again. I put a helluva lot of effort in
> to implement our discussion about adding a
> new category to jira so that we can classify
> issues properly and get a rough idea about what
> is needed for the release:
> http://forrest.apache.org/issues.html#priority
> http://forrest.apache.org/issues.html#urgency
> http://forrest.apache.org/issues.html#filters
How many times can I repeat myself in one mail:
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310000&fixfor=12310040
This roadmap was done before the urgency field was added, and I confess
I have not been through the whole thing again to add this field
information. I don't actually think there is a need to since I moved all
of the none core stuff out of the 0.8 release. Plugins can have
different release cycles (at least they can if we tidy of the versioned
plugins system - which is in the 0.8 roadmap). The urgency field is only
really important when plugins are thrown into the mix.
>>What are the improvements to Forrest other than dispatcher
>>that warrant there being a 0.8 release ?
>
>
> Lets make a dotpoint list here in email.
For my take on this see the (yawn) 0.8 roadmap. I'm not about to do it
all again - others can add/remove as they see fit. I'll re-emerge when
the discussion dies down and a vote is called.
> We could do a 0.7.1 release from the branch.
> However it would be better to release 0.8 which
> includes all those fixes and much more.
+1 to a 0.8 release when stuff is done
-0 to a 0.7.1 release
>>Should Dispatcher, although as you suggest, not part of the 0.8 release
>>program
>>and not holding up a 0.8 release, be moved from Whiteboard into core/plugin
>>at
>>the same time, now, or after ?
>
>
> Anytime. However it takes someone to research the
> side-effects, make a proposal, co-ordinate it.
>
> My current opinion is that it should happen after
> the release. Lets explore that topic in a separate
> thread.
That was the original plan: get 0.8 out, then do the integration work
for Dispatcher and get 0.9 out. 0.9 would also include the new
properties system, which is required by the dispatcher.
Of course, if dispatcher remains a plugin, it can be released at any time.
>>What are the incentives for users to upgrade to 0.8 from 0.7 ?
>
>
> See the need for release notes above.
One more time....
and the 0.8 roadmap in Jira ;-)
Ross
planning the 0.8 release (Was: [RT] structurer location and resource types)
Posted by David Crossley <cr...@apache.org>.
I am pulling the bits out of this RT that concern the
release. Please add more from the other replies.
This thread can identify what needs to be done.
Out of it we can develop a release plan which
defines a realistic target date. Voting on that
plan is necessary and has the advantage of drawing
attention to getting ready for the release.
Gav.... wrote:
> Thorsten Scherler wrote:
> >David Crossley escribi??:
> >>Please don't take my comments below the wrong way.
> >>I seek the best for the project.
> >>
> >>I know that this is a Random Thought thread but
> >>there seem to be some design and direction things
> >>which should break out into separate discussions.
People, please do this for other topics from that RT.
I am going away from the weekend so cannot do more.
We need to be able to focus ourselves and refer to
certain discussion. Otherwise we go in circles.
> >>Thorsten Scherler wrote:
> >>> Ross Gardler escribi??:
> >>>
> >>> Regarding backward compatible in general for views/dispatcher/... we
> >>> said that we do not care about it.
> >>
> >>Did we decide on a plan for removing those old
> >>plugins and docs before releasing 0.8?
> >
> >No, we have a couple of issues though:
> >http://issues.apache.org/jira/browse/FOR-798
> >http://issues.apache.org/jira/browse/FOR-797
>
> >It is nearly finished, but help is *very* welcome.
>
> If you give me an example of what needs changing I will have a go over the
> weekend.
>
> >>At some stage soon we do need to worry about
> >>backwards compatibility.
> >>
> >>
> >>I would like us to get moving on solving the
> >>general issues for the release, not just the
> >>dispatcher ones. We are dragging on too long.
> >
> >What are the general issues? Why do you think *we* are only focusing on
> >dispatcher ones?
>
> Dispatcher is moving along quickly, and so I guess is receiving a lot of
> focus
> at the moment, which is good. I do think though that other issues are
> taking a
> back seat at the moment. I for one have been focusing my attentions on
> getting
> dispatcher working on my system, trying to find things I could contribute
> to it,
> this has the impact of me not looking at Jira for other issues that need
> attention.
Well said Gav. This is what i meant by my comments.
None of us are even bothering to categorise the issues
in Jira, so that we know what needs to be done for the
release. Every ForrestFriday we say that we will do it
but we don't.
Attention is being drawn away from the release.
It is a natural thing for the exciting new development
to cause that. We need to balance that urge with
needing to get the release out the door.
> >>Anyway, this is an RT thread, so that is a topic
> >>for another thread.
> >>
> >>> More, I have reached the point in development (right now) where I see
> >>> the dispatcher way too forrest specific and I want to remove all what
> >>> is
> >>> "forrest only". There should be no code in the dispatcher that forces
> >>> the user to actually use forrest (forrest is one out of many excellent
> >>> frameworks), the dispatcher is an independent component/framework (well
> >>> heavily incooperating the lm) and should be seen as it.
> >>
> >>I know that this is an RT, but would it be better
> >>to get something that people can use and then we can
> >>refactor later.
> >
> >The dispatcher can be used and since 2 month we could have released the
> >dispatcher from the whiteboard (but I reckon if I am not starting this,
> >the dispatcher will remain forever in the whiteboard - no offense).
I was meaning to get the current implementation
tidied up, so that when we release we don't
create a maintenance and user support problem.
See discussion below.
> Should the release of the Dispatcher from the Whiteboard come before, after
> or at the same time as an official release of 0.8 ? Does releasing features
> from
> Whiteboard have an effect of a minor build release in its own right, whether
> it be dispatcher, or a plugin or some other Whiteboard event ?
Sorry no time to answer that today.
> >>We have halted development on skins.
> >>Now it looks like endless delays on the dispatcher.
> >
> >It is not because of the dispatcher, the dispatcher is not delaying
> >anything! Forrest core is delaying the release not the dispatcher.
> >
> >BTW we did not even start talking about releasing 0.8.
Ah, yes we have, many times. Often talked about finishing
locationmap and getting 0.8 out. Tidy up the plugins
and sitemaps and categorise issues for release.
It has also been one focus of every FirstFriday.
Yes i know that Dispatcher is not holding up the
release - we have specified that in past discussions.
My comment was meant to say: lets take a breath, pause,
tidy up, and get the release out ASAP.
> So lets talk about it, I guess we need to filter Jira for what IS holding up
> a 0.8 release and go through them. Perhaps the next Forrest Friday should
> focus on this.
Yes. Again. I put a helluva lot of effort in
to implement our discussion about adding a
new category to jira so that we can classify
issues properly and get a rough idea about what
is needed for the release:
http://forrest.apache.org/issues.html#priority
http://forrest.apache.org/issues.html#urgency
http://forrest.apache.org/issues.html#filters
> What are the improvements to Forrest other than dispatcher
> that warrant there being a 0.8 release ?
Lets make a dotpoint list here in email.
We will need that for the release notes anyway.
Actually what needs to happen is that we revise
status.xml to add missing entries and declare some
as "important" which gives us a generated list
which we can manually tweak to create the text for
the release email.
There is discussion in the archives that we don't
need to have any special new functionality to do
a release. Release early, release often is a must.
And we don't need to conserve our release numbers:
0.8, 0.9, 0.10, 0.11 is fine.
> Are bug fixes and patches from 0.7
> reason enough to release Forrest 0.8 without dispatcher being factored
> into it -- or are most bug fixes and patches from 0.7 in the current 0.7
> downloadable version ?
There only was every one release of 0.7 and
nothing gets added to it (see changes.html).
Crucial bugfixes are in SVN at branches/forrest_07_branch
All bugfixes are in the trunk.
Some committers have also added new functionality,
which is presumably duplicated in the trunk.
We could do a 0.7.1 release from the branch.
However it would be better to release 0.8 which
includes all those fixes and much more.
> Should Dispatcher, although as you suggest, not part of the 0.8 release
> program
> and not holding up a 0.8 release, be moved from Whiteboard into core/plugin
> at
> the same time, now, or after ?
Anytime. However it takes someone to research the
side-effects, make a proposal, co-ordinate it.
My current opinion is that it should happen after
the release. Lets explore that topic in a separate
thread.
In the recent tidy up of all plugins to get
consistent documentation and use of locationmap
we didn't tidy up any of the whiteboard plugins.
So when one is going to move, it needs such.
Not too hard, but takes effort.
No matter were it is located, we have some work
to do prior to the 0.8 release. It takes all of
us to pitch in to help and revise all of the
documentation (both in the main docs and the
plugin's own internal docs).
It needs to be clean and not confusing because
even though people have been warned that it is
still in-development, they will naturally use it
and come to rely on it.
So even though dispatcher doesn't hold up the
release, it needs to be in pretty good shape,
or we will get endless questions and confusion
on the users mailing list.
> What are the incentives for users to upgrade to 0.8 from 0.7 ?
See the need for release notes above.
-David
Re: [RT] structurer location and resource types
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "Thorsten Scherler" <th...@wyona.com>
To: <de...@forrest.apache.org>
Sent: Friday, March 24, 2006 9:00 PM
Subject: Re: [RT] structurer location and resource types
> El vie, 24-03-2006 a las 22:11 +1100, David Crossley escribió:
>> Please don't take my comments below the wrong way.
>> I seek the best for the project.
>>
>> I know that this is a Random Thought thread but
>> there seem to be some design and direction things
>> which should break out into separate discussions.
>>
>> Thorsten Scherler wrote:
>> > Ross Gardler escribi??:
>> > > Thorsten Scherler wrote:
>> > > > Thorsten Scherler escribi??:
>> > >
>> > > ...
>> > >
>> > > > IMO this internal structurer definition do not belong into the
>> > > > {xdocs}
>> > > > dir.
>> > > >
>> > > > Resource types specific structurer have to be stored in a different
>> > > > folder then the xdocs dir as well.
>> > > >
>> > > > IMO it makes sense to move them out of the xdocs dir and have
>> > > > something
>> > > > like
>> > > > structurer/
>> > > > |-- internal
>> > > > |-- resource-types
>> > > > `-- url
>> > >
>> > > Can the location be defined in either a property or the locationmap?
>> > > The
>> > > user should be able to specify these locations.
>> >
>> > Well, yes, since this location are *additions* to the current locations
>> > of the lm the user can override it on a project base. I do not find
>> > time
>> > to implement the forrest.properties.xml in the dispatcher ATM (and not
>> > in near future), so if somebody want to have this she needs to send a
>> > patch.
>> >
>> > > Your suggestion is fine for the defaults though.
>> > >
>> > > However, please, make this backward compatible. There are a number of
>> > > sites using Views and it is becoming really difficult to keep track.
>> > > Yes, I know it is in whiteboard, and that is the risk on takes, but
>> > > deprecating rather than removing would be more appropriate in this
>> > > stage
>> > > of the dispatchers development I would think.
>> >
>> > Like said this new locations will be added to the lm and they do not
>> > replace current ones. Sadly a @deprecate does only work on java files
>> > AFAIK, but we should update the docs that say to place it into the
>> > xdocs
>> > dir.
>> >
>> > Regarding backward compatible in general for views/dispatcher/... we
>> > said that we do not care about it.
>>
>> Did we decide on a plan for removing those old
>> plugins and docs before releasing 0.8?
>
> No, we have a couple of issues though:
> http://issues.apache.org/jira/browse/FOR-798
> http://issues.apache.org/jira/browse/FOR-797
>
> It is nearly finished, but help is *very* welcome.
If you give me an example of what needs changing I will have a go over the
weekend.
>
>>
>> At some stage soon we do need to worry about
>> backwards compatibility.
>>
>>
>> I would like us to get moving on solving the
>> general issues for the release, not just the
>> dispatcher ones. We are dragging on too long.
>
> What are the general issues? Why do you think *we* are only focusing on
> dispatcher ones?
Dispatcher is moving along quickly, and so I guess is receiving a lot of
focus
at the moment, which is good. I do think though that other issues are taking
a
back seat at the moment. I for one have been focusing my attentions on
getting
dispatcher working on my system, trying to find things I could contribute to
it,
this has the impact of me not looking at Jira for other issues that need
attention.
>
>>
>> Anyway, this is an RT thread, so that is a topic
>> for another thread.
>>
>> > More, I have reached the point in development (right now) where I see
>> > the dispatcher way too forrest specific and I want to remove all what
>> > is
>> > "forrest only". There should be no code in the dispatcher that forces
>> > the user to actually use forrest (forrest is one out of many excellent
>> > frameworks), the dispatcher is an independent component/framework (well
>> > heavily incooperating the lm) and should be seen as it.
>>
>> I know that this is an RT, but would it be better
>> to get something that people can use and then we can
>> refactor later.
>
> The dispatcher can be used and since 2 month we could have released the
> dispatcher from the whiteboard (but I reckon if I am not starting this,
> the dispatcher will remain forever in the whiteboard - no offense).
Should the release of the Dispatcher from the Whiteboard come before, after
or at the same time as an official release of 0.8 ? Does releasing features
from
Whiteboard have an effect of a minor build release in its own right, whether
it be dispatcher, or a plugin or some other Whiteboard event ?
>
>> We have halted development on skins.
>> Now it looks like endless delays on the dispatcher.
>
> It is not because of the dispatcher, the dispatcher is not delaying
> anything! Forrest core is delaying the release not the dispatcher.
>
> BTW we did not even start talking about releasing 0.8.
So lets talk about it, I guess we need to filter Jira for what IS holding up
a 0.8 release and go through them. Perhaps the next Forrest Friday should
focus on this. What are the improvements to Forrest other than dispatcher
that warrant there being a 0.8 release ? Are bug fixes and patches from 0.7
reason enough to release Forrest 0.8 without dispatcher being factored
into it -- or are most bug fixes and patches from 0.7 in the current 0.7
downloadable version ?
Should Dispatcher, although as you suggest, not part of the 0.8 release
program
and not holding up a 0.8 release, be moved from Whiteboard into core/plugin
at
the same time, now, or after ?
What are the incentives for users to upgrade to 0.8 from 0.7 ?
>
>> This is worrying.
>
> Well, yes and there are more stuff that worries me.
>
>>
>> > That leads to the need to extract as well the lm from forrest core and
>> > to make it to a component on its own (maybe to store the lm in a plugin
>> > makes the most sense).
>>
>> Or perhaps a Cocoon block that we maintain.
>
> good as gold
>
> +1
>
>>
>> > Actually I am thinking it would make sense to make the dispatcher a
>> > project on its own and support different frameworks, like e.g. Struts.
>> > Maybe starting as the first forrest subproject which offers different
>> > contracts/structurer for e.g. Lenya, forrest, cocoon, struts, ... as
>> > plugins, modules, ....
>>
>> I don't think that this project is big enough
>> to support sub-projects. We are barely a functioning
>> community at the moment. The number of truly active
>> developers is very small.
>
> Yes and I wish that our who.html would reflect the reality of active
> committer and not listing people as active that have not done a single
> commit/mail since years.
Is this a PMC decision, or should those now not currently active, mark
themselves as away for a while ? If it is a 'wish' then have a quick chat
about it
and do the neccessary, it might be an annoyance, but hardly a show-stopper,
so
get it sorted out of the way, or put it out of mind until more important
things are
out of the way.
>
> Anyway, the reality in this project is that the dispatcher has become a
> subproject of forrest. Further the dispatcher does not focus to support
> forrest only, I reviewed the dispatcher code and testing ATM to use it
> in the cocoon samples and it works quite nicely.
>
> Being a subproject does not mean that people will not help out here on
> forrest, but gives more freedom in releasing/refactoring and extending
> the dispatcher.
What will this mean to the rest of Forrest, will those working on Dispatcher
then move away from Forrest to concentrate on it? This will impact I guess
on Forrests core development, but it might also mean those that are left can
concentrate on Forrest and just 'use' dispatcher in a fashion similar to
Forrest
devs just 'use' Cocoon. Not sure if this isn't such a bad idea after all.
>
>>
>> > Further I am dreaming of a no-cocoon based
>> > implementation of the dispatcher, like as an extension for mozilla
>> > (written in POJ - I more and more understand Stefanos opinion "that
>> > cocoon has become obsolete").
>>
>> Well that is Stefano's opinion. Also he hasn't
>> been involved in Cocoon development for a long time.
>> Being a researcher it is not surprising that he
>> keeps moving on to new things.
>>
>> Forrest is still firmly based on Cocoon. We say so
>> in our project description. We need to be careful
>> not to destroy confidence by suggesting that it
>> is obsolete.
>
> Well I did not suggest it but rather stated that I *understand* his
> thoughts behind it. Let Forrest be firmly be based on cocoon but that
> should not mean that *all* components (or subprojects) have to be based
> on cocoon.
>
> See e.g. the forrestbar, that has nothing to do with cocoon at all. Even
> the dispatcher can be refactored relative quickly to be used in any
> application that can connect to java classes (like firefox 1.5.x).
>
>>
>> > That has as well the big advantage that forrest user do not have to use
>> > the dispatcher but can rather keep on using skins, which will stay the
>> > default rendering mechanism for forrest.
>>
>> Huh? I thought that we were deprecating skins.
>
> Lots of talk about it, but the reality seems different.
>
>> Perhaps we need to revisit that. Maybe we really
>> should provide two mechanims: skins and dispatcher.
>
> If so, who will do this? Like you stated yourself:
> "The number of truly active developers is very small."
>
> The dispatcher originally started to overcome the downsides of skins and
> actually it is (even in current development state) already better then
> skins. Skins are *only* working in forrest, the dispatcher is a
> standalone component.
>
> Further if somebody has the itch to extract all skin related code [which
> is deeply connected to the core, I tell from experience] into a skin
> plugin, I am all for having the two mechanism (factor me out for doing
> the skin plugins but I will help to remove all reference in the core to
> skins). http://issues.apache.org/jira/browse/FOR-808
>
> Having said this many times, I think we should let the dispatcher now
> grow independent from forrest.
> http://issues.apache.org/jira/browse/FOR-799
>
>>
>> I know we said that for the upcoming 0.8 release
>> that skins will still be the default. Is that what
>> you are referring to?
>
> I think many committers/dev/user are more committed to skins then to the
> dispatcher and this can be seen in the mail archives. That is perfectly
> ok, if those committers are willing to support skins in the future.
Dispatcher to many is not complete, is still new and still in Whiteboard,
and I
guess the fact that more are currently still skins biased is because of
this.
>
> The question is why would we want to keep skins as default and still not
> allow the dispatcher to become a subproject for a bigger audience then
> the forrest community?
>
> Even if the dispatcher becomes a sub-project of forrest (like shale in
> struts) we still can switch to the dispatcher as default any time.
You have a vision of Dispatcher that is bigger than most people here, the
fact
is that Dispatcher was born out of Forrest, from an idea based on skins and
all
its restrictions. Sure, move towards eventually making Dispatcher
standalone,
but I would not move it away from Forrest, although independent, Forrest I
would say relys on it in as much it relys on Cocoon. Without it, skins can
not
be deprecated.
I don't agree that skins should stay, that users have the choice of skins vs
dispatcher,
too messy, too confusing. Give them the choice, stay as they are with skins
and 0.7
and be supported with bug fixes for the time being - or upgrade to 0.8 and
later and
move onto the much nicer dispatcher., with I guess 0.9 removing skins
altogether.
Just my 2 cents :)
Gav...
>
> salu2
> --
> Thorsten Scherler
> COO Spain
> Wyona Inc. - Open Source Content Management - Apache Lenya
> http://www.wyona.com http://lenya.apache.org
> thorsten.scherler@wyona.com thorsten@apache.org
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.3.0/290 - Release Date: 23/03/2006
>
Re: [RT] structurer location and resource types
Posted by Thorsten Scherler <th...@wyona.com>.
El vie, 24-03-2006 a las 22:11 +1100, David Crossley escribió:
> Please don't take my comments below the wrong way.
> I seek the best for the project.
>
> I know that this is a Random Thought thread but
> there seem to be some design and direction things
> which should break out into separate discussions.
>
> Thorsten Scherler wrote:
> > Ross Gardler escribi??:
> > > Thorsten Scherler wrote:
> > > > Thorsten Scherler escribi??:
> > >
> > > ...
> > >
> > > > IMO this internal structurer definition do not belong into the {xdocs}
> > > > dir.
> > > >
> > > > Resource types specific structurer have to be stored in a different
> > > > folder then the xdocs dir as well.
> > > >
> > > > IMO it makes sense to move them out of the xdocs dir and have something
> > > > like
> > > > structurer/
> > > > |-- internal
> > > > |-- resource-types
> > > > `-- url
> > >
> > > Can the location be defined in either a property or the locationmap? The
> > > user should be able to specify these locations.
> >
> > Well, yes, since this location are *additions* to the current locations
> > of the lm the user can override it on a project base. I do not find time
> > to implement the forrest.properties.xml in the dispatcher ATM (and not
> > in near future), so if somebody want to have this she needs to send a
> > patch.
> >
> > > Your suggestion is fine for the defaults though.
> > >
> > > However, please, make this backward compatible. There are a number of
> > > sites using Views and it is becoming really difficult to keep track.
> > > Yes, I know it is in whiteboard, and that is the risk on takes, but
> > > deprecating rather than removing would be more appropriate in this stage
> > > of the dispatchers development I would think.
> >
> > Like said this new locations will be added to the lm and they do not
> > replace current ones. Sadly a @deprecate does only work on java files
> > AFAIK, but we should update the docs that say to place it into the xdocs
> > dir.
> >
> > Regarding backward compatible in general for views/dispatcher/... we
> > said that we do not care about it.
>
> Did we decide on a plan for removing those old
> plugins and docs before releasing 0.8?
No, we have a couple of issues though:
http://issues.apache.org/jira/browse/FOR-798
http://issues.apache.org/jira/browse/FOR-797
It is nearly finished, but help is *very* welcome.
>
> At some stage soon we do need to worry about
> backwards compatibility.
>
>
> I would like us to get moving on solving the
> general issues for the release, not just the
> dispatcher ones. We are dragging on too long.
What are the general issues? Why do you think *we* are only focusing on
dispatcher ones?
>
> Anyway, this is an RT thread, so that is a topic
> for another thread.
>
> > More, I have reached the point in development (right now) where I see
> > the dispatcher way too forrest specific and I want to remove all what is
> > "forrest only". There should be no code in the dispatcher that forces
> > the user to actually use forrest (forrest is one out of many excellent
> > frameworks), the dispatcher is an independent component/framework (well
> > heavily incooperating the lm) and should be seen as it.
>
> I know that this is an RT, but would it be better
> to get something that people can use and then we can
> refactor later.
The dispatcher can be used and since 2 month we could have released the
dispatcher from the whiteboard (but I reckon if I am not starting this,
the dispatcher will remain forever in the whiteboard - no offense).
> We have halted development on skins.
> Now it looks like endless delays on the dispatcher.
It is not because of the dispatcher, the dispatcher is not delaying
anything! Forrest core is delaying the release not the dispatcher.
BTW we did not even start talking about releasing 0.8.
> This is worrying.
Well, yes and there are more stuff that worries me.
>
> > That leads to the need to extract as well the lm from forrest core and
> > to make it to a component on its own (maybe to store the lm in a plugin
> > makes the most sense).
>
> Or perhaps a Cocoon block that we maintain.
good as gold
+1
>
> > Actually I am thinking it would make sense to make the dispatcher a
> > project on its own and support different frameworks, like e.g. Struts.
> > Maybe starting as the first forrest subproject which offers different
> > contracts/structurer for e.g. Lenya, forrest, cocoon, struts, ... as
> > plugins, modules, ....
>
> I don't think that this project is big enough
> to support sub-projects. We are barely a functioning
> community at the moment. The number of truly active
> developers is very small.
Yes and I wish that our who.html would reflect the reality of active
committer and not listing people as active that have not done a single
commit/mail since years.
Anyway, the reality in this project is that the dispatcher has become a
subproject of forrest. Further the dispatcher does not focus to support
forrest only, I reviewed the dispatcher code and testing ATM to use it
in the cocoon samples and it works quite nicely.
Being a subproject does not mean that people will not help out here on
forrest, but gives more freedom in releasing/refactoring and extending
the dispatcher.
>
> > Further I am dreaming of a no-cocoon based
> > implementation of the dispatcher, like as an extension for mozilla
> > (written in POJ - I more and more understand Stefanos opinion "that
> > cocoon has become obsolete").
>
> Well that is Stefano's opinion. Also he hasn't
> been involved in Cocoon development for a long time.
> Being a researcher it is not surprising that he
> keeps moving on to new things.
>
> Forrest is still firmly based on Cocoon. We say so
> in our project description. We need to be careful
> not to destroy confidence by suggesting that it
> is obsolete.
Well I did not suggest it but rather stated that I *understand* his
thoughts behind it. Let Forrest be firmly be based on cocoon but that
should not mean that *all* components (or subprojects) have to be based
on cocoon.
See e.g. the forrestbar, that has nothing to do with cocoon at all. Even
the dispatcher can be refactored relative quickly to be used in any
application that can connect to java classes (like firefox 1.5.x).
>
> > That has as well the big advantage that forrest user do not have to use
> > the dispatcher but can rather keep on using skins, which will stay the
> > default rendering mechanism for forrest.
>
> Huh? I thought that we were deprecating skins.
Lots of talk about it, but the reality seems different.
> Perhaps we need to revisit that. Maybe we really
> should provide two mechanims: skins and dispatcher.
If so, who will do this? Like you stated yourself:
"The number of truly active developers is very small."
The dispatcher originally started to overcome the downsides of skins and
actually it is (even in current development state) already better then
skins. Skins are *only* working in forrest, the dispatcher is a
standalone component.
Further if somebody has the itch to extract all skin related code [which
is deeply connected to the core, I tell from experience] into a skin
plugin, I am all for having the two mechanism (factor me out for doing
the skin plugins but I will help to remove all reference in the core to
skins). http://issues.apache.org/jira/browse/FOR-808
Having said this many times, I think we should let the dispatcher now
grow independent from forrest.
http://issues.apache.org/jira/browse/FOR-799
>
> I know we said that for the upcoming 0.8 release
> that skins will still be the default. Is that what
> you are referring to?
I think many committers/dev/user are more committed to skins then to the
dispatcher and this can be seen in the mail archives. That is perfectly
ok, if those committers are willing to support skins in the future.
The question is why would we want to keep skins as default and still not
allow the dispatcher to become a subproject for a bigger audience then
the forrest community?
Even if the dispatcher becomes a sub-project of forrest (like shale in
struts) we still can switch to the dispatcher as default any time.
salu2
--
Thorsten Scherler
COO Spain
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
thorsten.scherler@wyona.com thorsten@apache.org
Re: [RT] structurer location and resource types
Posted by Thorsten Scherler <th...@apache.org>.
El vie, 24-03-2006 a las 07:36 -0500, Tim Williams escribió:
...
> >
> > > Further I am dreaming of a no-cocoon based
> > > implementation of the dispatcher, like as an extension for mozilla
> > > (written in POJ - I more and more understand Stefanos opinion "that
> > > cocoon has become obsolete").
> >
> > Well that is Stefano's opinion. Also he hasn't
>
> He sent a strongly titled and provocative email for effective.
> There's a lot more to it than that and concluding that "Stefanos
> opinion is that cocoon has become obsolete" is hasty and unfair all
> the way around.
>
> http://www.betaversion.org/~stefano/linotype/news/94/
"Just before last weekend, during my final Piggy Bank wrap-up's, I sent
an email to the Cocoon development mailling list airing my concerns: the
web is slowly but surely changing.
...
Cocoon is clearly not obsolete and it won't be for a while, but it's fat
and sleepy, kinda watching TV (if you allow me) instead of going out
exercizing. Before I move on, I wanted to trigger a wake up call.
..."
I share this observations, cocoon is one out of many and not the "one".
There is going on a revolution in web development and cocoon is too FAT
and far from being an industry standard like Struts or httpd were/are.
All, just read the link Tim provided (thx Tim) and you may understand
why I would like to have <1MB core where I base my code on.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [RT] structurer location and resource types
Posted by Tim Williams <wi...@gmail.com>.
On 3/24/06, David Crossley <cr...@apache.org> wrote:
> Please don't take my comments below the wrong way.
> I seek the best for the project.
>
> I know that this is a Random Thought thread but
> there seem to be some design and direction things
> which should break out into separate discussions.
>
> Thorsten Scherler wrote:
> > Ross Gardler escribi??:
> > > Thorsten Scherler wrote:
> > > > Thorsten Scherler escribi??:
> > >
> > > ...
> > >
> > > > IMO this internal structurer definition do not belong into the {xdocs}
> > > > dir.
> > > >
> > > > Resource types specific structurer have to be stored in a different
> > > > folder then the xdocs dir as well.
> > > >
> > > > IMO it makes sense to move them out of the xdocs dir and have something
> > > > like
> > > > structurer/
> > > > |-- internal
> > > > |-- resource-types
> > > > `-- url
> > >
> > > Can the location be defined in either a property or the locationmap? The
> > > user should be able to specify these locations.
> >
> > Well, yes, since this location are *additions* to the current locations
> > of the lm the user can override it on a project base. I do not find time
> > to implement the forrest.properties.xml in the dispatcher ATM (and not
> > in near future), so if somebody want to have this she needs to send a
> > patch.
> >
> > > Your suggestion is fine for the defaults though.
> > >
> > > However, please, make this backward compatible. There are a number of
> > > sites using Views and it is becoming really difficult to keep track.
> > > Yes, I know it is in whiteboard, and that is the risk on takes, but
> > > deprecating rather than removing would be more appropriate in this stage
> > > of the dispatchers development I would think.
> >
> > Like said this new locations will be added to the lm and they do not
> > replace current ones. Sadly a @deprecate does only work on java files
> > AFAIK, but we should update the docs that say to place it into the xdocs
> > dir.
> >
> > Regarding backward compatible in general for views/dispatcher/... we
> > said that we do not care about it.
>
> Did we decide on a plan for removing those old
> plugins and docs before releasing 0.8?
>
> At some stage soon we do need to worry about
> backwards compatibility.
>
>
> I would like us to get moving on solving the
> general issues for the release, not just the
> dispatcher ones. We are dragging on too long.
>
> Anyway, this is an RT thread, so that is a topic
> for another thread.
>
> > More, I have reached the point in development (right now) where I see
> > the dispatcher way too forrest specific and I want to remove all what is
> > "forrest only". There should be no code in the dispatcher that forces
> > the user to actually use forrest (forrest is one out of many excellent
> > frameworks), the dispatcher is an independent component/framework (well
> > heavily incooperating the lm) and should be seen as it.
>
> I know that this is an RT, but would it be better
> to get something that people can use and then we can
> refactor later. We have halted development on skins.
> Now it looks like endless delays on the dispatcher.
> This is worrying.
>
> > That leads to the need to extract as well the lm from forrest core and
> > to make it to a component on its own (maybe to store the lm in a plugin
> > makes the most sense).
>
> Or perhaps a Cocoon block that we maintain.
>
> > Actually I am thinking it would make sense to make the dispatcher a
> > project on its own and support different frameworks, like e.g. Struts.
> > Maybe starting as the first forrest subproject which offers different
> > contracts/structurer for e.g. Lenya, forrest, cocoon, struts, ... as
> > plugins, modules, ....
>
> I don't think that this project is big enough
> to support sub-projects. We are barely a functioning
> community at the moment. The number of truly active
> developers is very small.
>
> > Further I am dreaming of a no-cocoon based
> > implementation of the dispatcher, like as an extension for mozilla
> > (written in POJ - I more and more understand Stefanos opinion "that
> > cocoon has become obsolete").
>
> Well that is Stefano's opinion. Also he hasn't
He sent a strongly titled and provocative email for effective.
There's a lot more to it than that and concluding that "Stefanos
opinion is that cocoon has become obsolete" is hasty and unfair all
the way around.
http://www.betaversion.org/~stefano/linotype/news/94/
--tim
Re: [RT] structurer location and resource types
Posted by David Crossley <cr...@apache.org>.
Please don't take my comments below the wrong way.
I seek the best for the project.
I know that this is a Random Thought thread but
there seem to be some design and direction things
which should break out into separate discussions.
Thorsten Scherler wrote:
> Ross Gardler escribi??:
> > Thorsten Scherler wrote:
> > > Thorsten Scherler escribi??:
> >
> > ...
> >
> > > IMO this internal structurer definition do not belong into the {xdocs}
> > > dir.
> > >
> > > Resource types specific structurer have to be stored in a different
> > > folder then the xdocs dir as well.
> > >
> > > IMO it makes sense to move them out of the xdocs dir and have something
> > > like
> > > structurer/
> > > |-- internal
> > > |-- resource-types
> > > `-- url
> >
> > Can the location be defined in either a property or the locationmap? The
> > user should be able to specify these locations.
>
> Well, yes, since this location are *additions* to the current locations
> of the lm the user can override it on a project base. I do not find time
> to implement the forrest.properties.xml in the dispatcher ATM (and not
> in near future), so if somebody want to have this she needs to send a
> patch.
>
> > Your suggestion is fine for the defaults though.
> >
> > However, please, make this backward compatible. There are a number of
> > sites using Views and it is becoming really difficult to keep track.
> > Yes, I know it is in whiteboard, and that is the risk on takes, but
> > deprecating rather than removing would be more appropriate in this stage
> > of the dispatchers development I would think.
>
> Like said this new locations will be added to the lm and they do not
> replace current ones. Sadly a @deprecate does only work on java files
> AFAIK, but we should update the docs that say to place it into the xdocs
> dir.
>
> Regarding backward compatible in general for views/dispatcher/... we
> said that we do not care about it.
Did we decide on a plan for removing those old
plugins and docs before releasing 0.8?
At some stage soon we do need to worry about
backwards compatibility.
I would like us to get moving on solving the
general issues for the release, not just the
dispatcher ones. We are dragging on too long.
Anyway, this is an RT thread, so that is a topic
for another thread.
> More, I have reached the point in development (right now) where I see
> the dispatcher way too forrest specific and I want to remove all what is
> "forrest only". There should be no code in the dispatcher that forces
> the user to actually use forrest (forrest is one out of many excellent
> frameworks), the dispatcher is an independent component/framework (well
> heavily incooperating the lm) and should be seen as it.
I know that this is an RT, but would it be better
to get something that people can use and then we can
refactor later. We have halted development on skins.
Now it looks like endless delays on the dispatcher.
This is worrying.
> That leads to the need to extract as well the lm from forrest core and
> to make it to a component on its own (maybe to store the lm in a plugin
> makes the most sense).
Or perhaps a Cocoon block that we maintain.
> Actually I am thinking it would make sense to make the dispatcher a
> project on its own and support different frameworks, like e.g. Struts.
> Maybe starting as the first forrest subproject which offers different
> contracts/structurer for e.g. Lenya, forrest, cocoon, struts, ... as
> plugins, modules, ....
I don't think that this project is big enough
to support sub-projects. We are barely a functioning
community at the moment. The number of truly active
developers is very small.
> Further I am dreaming of a no-cocoon based
> implementation of the dispatcher, like as an extension for mozilla
> (written in POJ - I more and more understand Stefanos opinion "that
> cocoon has become obsolete").
Well that is Stefano's opinion. Also he hasn't
been involved in Cocoon development for a long time.
Being a researcher it is not surprising that he
keeps moving on to new things.
Forrest is still firmly based on Cocoon. We say so
in our project description. We need to be careful
not to destroy confidence by suggesting that it
is obsolete.
> That has as well the big advantage that forrest user do not have to use
> the dispatcher but can rather keep on using skins, which will stay the
> default rendering mechanism for forrest.
Huh? I thought that we were deprecating skins.
Perhaps we need to revisit that. Maybe we really
should provide two mechanims: skins and dispatcher.
I know we said that for the upcoming 0.8 release
that skins will still be the default. Is that what
you are referring to?
-David
Re: [RT] structurer location and resource types (was
Re: [announcement] DOCO prototype in forrest and lenya rep)
Posted by Thorsten Scherler <th...@wyona.com>.
El mié, 22-03-2006 a las 11:06 +0000, Ross Gardler escribió:
> Thorsten Scherler wrote:
> > El mar, 21-03-2006 a las 10:53 +0100, Thorsten Scherler escribió:
>
> ...
>
> > IMO this internal structurer definition do not belong into the {xdocs}
> > dir.
> >
> > Resource types specific structurer have to be stored in a different
> > folder then the xdocs dir as well.
> >
> > IMO it makes sense to move them out of the xdocs dir and have something
> > like
> > structurer/
> > |-- internal
> > |-- resource-types
> > `-- url
>
> Can the location be defined in either a property or the locationmap? The
> user should be able to specify these locations.
>
Well, yes, since this location are *additions* to the current locations
of the lm the user can override it on a project base. I do not find time
to implement the forrest.properties.xml in the dispatcher ATM (and not
in near future), so if somebody want to have this she needs to send a
patch.
> Your suggestion is fine for the defaults though.
>
> However, please, make this backward compatible. There are a number of
> sites using Views and it is becoming really difficult to keep track.
> Yes, I know it is in whiteboard, and that is the risk on takes, but
> deprecating rather than removing would be more appropriate in this stage
> of the dispatchers development I would think.
Like said this new locations will be added to the lm and they do not
replace current ones. Sadly a @deprecate does only work on java files
AFAIK, but we should update the docs that say to place it into the xdocs
dir.
Regarding backward compatible in general for views/dispatcher/... we
said that we do not care about it.
More, I have reached the point in development (right now) where I see
the dispatcher way too forrest specific and I want to remove all what is
"forrest only". There should be no code in the dispatcher that forces
the user to actually use forrest (forrest is one out of many excellent
frameworks), the dispatcher is an independent component/framework (well
heavily incooperating the lm) and should be seen as it.
That leads to the need to extract as well the lm from forrest core and
to make it to a component on its own (maybe to store the lm in a plugin
makes the most sense).
Actually I am thinking it would make sense to make the dispatcher a
project on its own and support different frameworks, like e.g. Struts.
Maybe starting as the first forrest subproject which offers different
contracts/structurer for e.g. Lenya, forrest, cocoon, struts, ... as
plugins, modules, .... Further I am dreaming of a no-cocoon based
implementation of the dispatcher, like as an extension for mozilla
(written in POJ - I more and more understand Stefanos opinion "that
cocoon has become obsolete").
That has as well the big advantage that forrest user do not have to use
the dispatcher but can rather keep on using skins, which will stay the
default rendering mechanism for forrest.
>
> > To solve FOR-621 with http://forrest.apache.org/docs_0_80/cap.html is
> > not enough.
> >
> > "SourceTypeAction assigns a "type" (a string) to an XML file. This is
> > done based on information occuring in the header of the XML file, up to
> > the document (root) element."
> >
> > This solution works perfectly for xml files but there are so many
> > non-xml files and formats that can mean a different source type and
> > needs a different structurer.
> >
> > We need a counterpart of the SourceTypeAction for non-xml formats and
> > keeping such information in meta data seems the most logical way.
> >
> > wdyt?
>
> How are we to process non-XML formats in an XML publishing environment?
> Can you give an example of the kind of file you are thinking of
> processing in this way.
All binary files. In lenya we are discussing this ATM regarding
resources. A image is content as xml, as plain text, as ... Now imagine
a movie as content, this movie can have meta data and we could render
this meta data in combination with the movie to a view-movie page
(containing the mov and the meta data information). Or to a edit-movie
page (if we find e.g. a movie editor that works in a browser).
>
> I ask because at present all non-xml files are simply read and served.
Yeah, we are doing the same error here as in lenya and ignoring this
files. Further we are "hidding" the processing within high complex code
like our core resource.xmap (lots of magic and no comments).
> It sounds to me like you have a way of improving on this, but I don't
> understand how.
>
> Ross
Well think of the libary on your computer that is connecting file
extensions with applications. e.g. as soon as I click on a png, gimp is
opening up. This is the same idea but in a *web based* environment. Who
said one cannot edit an image with the browser? ;)
salu2
--
Thorsten Scherler
COO Spain
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
thorsten.scherler@wyona.com thorsten@apache.org
Re: [RT] structurer location and resource types (was Re: [announcement]
DOCO prototype in forrest and lenya rep)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> El mar, 21-03-2006 a las 10:53 +0100, Thorsten Scherler escribió:
...
> IMO this internal structurer definition do not belong into the {xdocs}
> dir.
>
> Resource types specific structurer have to be stored in a different
> folder then the xdocs dir as well.
>
> IMO it makes sense to move them out of the xdocs dir and have something
> like
> structurer/
> |-- internal
> |-- resource-types
> `-- url
Can the location be defined in either a property or the locationmap? The
user should be able to specify these locations.
Your suggestion is fine for the defaults though.
However, please, make this backward compatible. There are a number of
sites using Views and it is becoming really difficult to keep track.
Yes, I know it is in whiteboard, and that is the risk on takes, but
deprecating rather than removing would be more appropriate in this stage
of the dispatchers development I would think.
> To solve FOR-621 with http://forrest.apache.org/docs_0_80/cap.html is
> not enough.
>
> "SourceTypeAction assigns a "type" (a string) to an XML file. This is
> done based on information occuring in the header of the XML file, up to
> the document (root) element."
>
> This solution works perfectly for xml files but there are so many
> non-xml files and formats that can mean a different source type and
> needs a different structurer.
>
> We need a counterpart of the SourceTypeAction for non-xml formats and
> keeping such information in meta data seems the most logical way.
>
> wdyt?
How are we to process non-XML formats in an XML publishing environment?
Can you give an example of the kind of file you are thinking of
processing in this way.
I ask because at present all non-xml files are simply read and served.
It sounds to me like you have a way of improving on this, but I don't
understand how.
Ross