planning the 0.8 release (Was: [RT] structurer location and resource types)

[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: planning the 0.8 release (Was: [RT] structurer location and resource types)

[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

[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

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

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

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

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

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

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

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

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

["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)

[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