Blocking Issues

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

Devs,
The following are the issues considered "blockers".  I feel
comfortable moving others under lazy consensus to the next release,
but I felt there was a higher burden for these.  I figure if someone
thought they blocked at the time, then I reckon they should get a
say...  Anyway, can you peruse these issues and comment on any that
you feel strongly about?

FOR-681	Include xconf files in plugins using includes, not XPatch
- I don't know, a blocker?

FOR-796	Merge all view/dispatcher work into
org.apache.forrest.plugin.internal.dispatcher and
org.apache.forrest.themes.core
- Thorsten's looking at this now.

FOR-911	decide content of release	
- I recommend punting on this one, we can do what we've always done.

FOR-868	add relevant notes to the "Upgrading" xdoc
- housekeeping

FOR-1108	Dispatcher, Cocoon 2.1 and Windows	
- I dunno

FOR-591	MaxMemory needs increasing for large document sets: Memory
Leak with XMLFileModule
- I'll give this another yet another attempt.

FOR-855	verify the license situation prior to each release
- housekeeping

FOR-1177	where does forrest use Rhino

FOR-812	Remove dependency of projectInfo on skinconf.xml
- maybe I don't understand it fully, but it doesn't seem like it
should block us from a release

Thanks,
--tim

Re: Blocking Issues

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

Tim Williams wrote:
>
> The following are the issues considered "blockers".  I feel
> comfortable moving others under lazy consensus to the next release,

Oh, good on you Tim. I meant to say something a few days ago
when you started to review the Issues situation. That is what
it takes to start things moving.

I am away for the weekend so will comment later.

One thing that i wanted to remind all developers, not just
committers, is to please review the list of all issues too
to look for other potential blockers. Since the last release
we have not really kept up with categorising the issues.

See https://issues.apache.org/jira/browse/FOR
and skim through the "0.9-dev" and "unscheduled" list.

Of course if other issues take your fancy then just attend to them,
but the purpose of this is to find unclassified blockers.

-David

Re: Blocking Issues

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

On Tue, Nov 24, 2009 at 3:33 AM, Ross Gardler <rg...@apache.org> wrote:
> 2009/11/24 David Crossley <cr...@apache.org>:
>> Ross Gardler wrote:
>>> David Crossley wrote:
>>> > Ross Gardler wrote:
>>> >> David Crossley wrote:
>>> >> > Ross Gardler wrote:
>>> >> >> Tim Williams wrote:
>>> >> >> >
>>> >> >> > FOR-855 verify the license situation prior to each release
>>> >> >> > - housekeeping
>>> >> >>
>>> >> >> I believe Davids work with RAT fixes this issue.
>>> >> >
>>> >> > No it does not. There is much more to the job that that.
>>> >>
>>> >> I meant that running RAT shows all licence headers are in place. we
>>> >> still need to do the housekeeping work that is normal due diligence on
>>> >> a release, of course.
>>> >
>>> > I meant that FOR-855 has much more than just the license header situation.
>>> > I have been working on it steadily for a long time now, and there is more
>>> > to do.
>>>
>>> OK, I should have reviewed the issue. I have no opinion on whether
>>> this is a blocker or not. I assumed that previous releases were
>>> legally sound (which I believe they were since we voted them through).
>>
>> We have cut corners on previous releases. Our top-level LICENSE.txt file
>> is not in line with agreed ASF best practice. It is supposed to display
>> relevant licenses for supporting products.
>
> Hmm.... not good.
>
> I wonder if this has occured as things have crept into plugins.
> Perhaps each plugin should have a licence.txt file and the build
> system should merge them together at build time.
>
>> Also all supporting product licenses need to be systematically reviewed.
>> Since the last release some things have been haphazardly added to SVN.
>> Also last time we could easily have missed some.
>
> I've tried to review every commit for such things. I hope others have
> been doing the same to catch the ones I miss. I'm pretty sure that a
> review of licences is already in the release workflow - if not it
> should be, for the reasons you give.
>
>>> Tim indicated that this was "housekeeping" which I took to mean the
>>> normal due diligence on a release.
>>
>> Yes, but i marked it as Blocker (same process as i did for the previous
>> releases) because a release should not be rolled until the situation is
>> suitable.
>
> I'm not saying it is not a blocker, I'm agreeing it is part of the
> required housekeeping of a release. In other words we are in agreement
> ;-)

Sorry, I might have inadvertently caused this confusion with my
imprecise wording, "housekeeping," which seems to have unintentionally
trivialized it.  I meant it as in "a necessary part of the release
process" as opposed to, say, a "bug".

>> I will plod along with FOR-855 and FOR-857 while other people
>> attend to other things.
>
> Thank you. I'd like to say I'd help, but to be honest I doubt I'll
> find the time.

I'm going out of town for a week for our Thanksgiving holidays here in
America, I'll pick this up when I get back...
Thanks,
--tim

Re: Blocking Issues

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

2009/11/24 David Crossley <cr...@apache.org>:
> Ross Gardler wrote:
>> David Crossley wrote:
>> > Ross Gardler wrote:
>> >> David Crossley wrote:
>> >> > Ross Gardler wrote:
>> >> >> Tim Williams wrote:
>> >> >> >
>> >> >> > FOR-855 verify the license situation prior to each release
>> >> >> > - housekeeping
>> >> >>
>> >> >> I believe Davids work with RAT fixes this issue.
>> >> >
>> >> > No it does not. There is much more to the job that that.
>> >>
>> >> I meant that running RAT shows all licence headers are in place. we
>> >> still need to do the housekeeping work that is normal due diligence on
>> >> a release, of course.
>> >
>> > I meant that FOR-855 has much more than just the license header situation.
>> > I have been working on it steadily for a long time now, and there is more
>> > to do.
>>
>> OK, I should have reviewed the issue. I have no opinion on whether
>> this is a blocker or not. I assumed that previous releases were
>> legally sound (which I believe they were since we voted them through).
>
> We have cut corners on previous releases. Our top-level LICENSE.txt file
> is not in line with agreed ASF best practice. It is supposed to display
> relevant licenses for supporting products.

Hmm.... not good.

I wonder if this has occured as things have crept into plugins.
Perhaps each plugin should have a licence.txt file and the build
system should merge them together at build time.

> Also all supporting product licenses need to be systematically reviewed.
> Since the last release some things have been haphazardly added to SVN.
> Also last time we could easily have missed some.

I've tried to review every commit for such things. I hope others have
been doing the same to catch the ones I miss. I'm pretty sure that a
review of licences is already in the release workflow - if not it
should be, for the reasons you give.

>> Tim indicated that this was "housekeeping" which I took to mean the
>> normal due diligence on a release.
>
> Yes, but i marked it as Blocker (same process as i did for the previous
> releases) because a release should not be rolled until the situation is
> suitable.

I'm not saying it is not a blocker, I'm agreeing it is part of the
required housekeeping of a release. In other words we are in agreement
;-)

> I will plod along with FOR-855 and FOR-857 while other people
> attend to other things.

Thank you. I'd like to say I'd help, but to be honest I doubt I'll
find the time.

Ross

Re: Blocking Issues

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

Ross Gardler wrote:
> David Crossley wrote: 
> > Ross Gardler wrote:
> >> David Crossley wrote:
> >> > Ross Gardler wrote:
> >> >> Tim Williams wrote:
> >> >> >
> >> >> > FOR-855 verify the license situation prior to each release
> >> >> > - housekeeping
> >> >>
> >> >> I believe Davids work with RAT fixes this issue.
> >> >
> >> > No it does not. There is much more to the job that that.
> >>
> >> I meant that running RAT shows all licence headers are in place. we
> >> still need to do the housekeeping work that is normal due diligence on
> >> a release, of course.
> >
> > I meant that FOR-855 has much more than just the license header situation.
> > I have been working on it steadily for a long time now, and there is more
> > to do.
> 
> OK, I should have reviewed the issue. I have no opinion on whether
> this is a blocker or not. I assumed that previous releases were
> legally sound (which I believe they were since we voted them through).

We have cut corners on previous releases. Our top-level LICENSE.txt file
is not in line with agreed ASF best practice. It is supposed to display
relevant licenses for supporting products.

Also all supporting product licenses need to be systematically reviewed.
Since the last release some things have been haphazardly added to SVN.
Also last time we could easily have missed some.

> Tim indicated that this was "housekeeping" which I took to mean the
> normal due diligence on a release.

Yes, but i marked it as Blocker (same process as i did for the previous
releases) because a release should not be rolled until the situation is
suitable.

I will plod along with FOR-855 and FOR-857 while other people
attend to other things.

-David

Re: Blocking Issues

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

2009/11/23 David Crossley <cr...@apache.org>:
> Ross Gardler wrote:
>> David Crossley  wrote:
>> > Ross Gardler wrote:
>> >> Tim Williams wrote:
>> >> >
>> >> > FOR-855 verify the license situation prior to each release
>> >> > - housekeeping
>> >>
>> >> I believe Davids work with RAT fixes this issue.
>> >
>> > No it does not. There is much more to the job that that.
>>
>> I meant that running RAT shows all licence headers are in place. we
>> still need to do the housekeeping work that is normal due diligence on
>> a release, of course.
>
> I meant that FOR-855 has much more than just the license header situation.
> I have been working on it steadily for a long time now, and there is more
> to do.

OK, I should have reviewed the issue. I have no opinion on whether
this is a blocker or not. I assumed that previous releases were
legally sound (which I believe they were since we voted them through).
Tim indicated that this was "housekeeping" which I took to mean the
normal due diligence on a release.

>> >> > FOR-1177 where does forrest use Rhino
>> >>
>> >> Not a blocker
>> >
>> > Yes it is. At the moment i think that it might be using an
>> > unsuitable license.
>>
>> Why? Rhino is dual licensed under GPL and MPL. MPL is compatible, as
>> long as we have the relevant NOTICE file. What am I missing that you
>> are seeing?
>
> I will try to clarify it at FOR-1177. When our packaged version of
> Rhino was prepared, it was probably the old NPL-licensed one.

OK, so that's probably a blocker then - we need to update to the MPL version.

Ross

Re: Blocking Issues

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

Ross Gardler wrote:
> David Crossley  wrote:
> > Ross Gardler wrote:
> >> Tim Williams wrote:
> >> >
> >> > FOR-855 verify the license situation prior to each release
> >> > - housekeeping
> >>
> >> I believe Davids work with RAT fixes this issue.
> >
> > No it does not. There is much more to the job that that.
> 
> I meant that running RAT shows all licence headers are in place. we
> still need to do the housekeeping work that is normal due diligence on
> a release, of course.

I meant that FOR-855 has much more than just the license header situation.
I have been working on it steadily for a long time now, and there is more
to do.

> >> > FOR-1177 where does forrest use Rhino
> >>
> >> Not a blocker
> >
> > Yes it is. At the moment i think that it might be using an
> > unsuitable license.
> 
> Why? Rhino is dual licensed under GPL and MPL. MPL is compatible, as
> long as we have the relevant NOTICE file. What am I missing that you
> are seeing?

I will try to clarify it at FOR-1177. When our packaged version of
Rhino was prepared, it was probably the old NPL-licensed one.

-David

Re: Blocking Issues

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

2009/11/21 David Crossley <cr...@apache.org>:
> Ross Gardler wrote:
>> Tim Williams wrote:
>> >
>> > FOR-855 verify the license situation prior to each release
>> > - housekeeping
>>
>> I believe Davids work with RAT fixes this issue.
>
> No it does not. There is much more to the job that that.

I meant that running RAT shows all licence headers are in place. we
still need to do the housekeeping work that is normal due diligence on
a release, of course.

>> > FOR-1177 ? ? ? ?where does forrest use Rhino
>>
>> Not a blocker
>
> Yes it is. At the moment i think that it might be using an
> unsuitable license.

Why? Rhino is dual licensed under GPL and MPL. MPL is compatible, as
long as we have the relevant NOTICE file. What am I missing that you
are seeing?

Ross

Re: Blocking Issues

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

Ross Gardler wrote:
> Tim Williams wrote:
> >
> > FOR-855 verify the license situation prior to each release
> > - housekeeping
> 
> I believe Davids work with RAT fixes this issue.

No it does not. There is much more to the job that that.

> > FOR-1177 ? ? ? ?where does forrest use Rhino
> 
> Not a blocker

Yes it is. At the moment i think that it might be using an
unsuitable license.

-David

Re: Blocking Issues

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

2009/11/20 Tim Williams <wi...@gmail.com>:
> Devs,
> The following are the issues considered "blockers".  I feel
> comfortable moving others under lazy consensus to the next release,
> but I felt there was a higher burden for these.  I figure if someone
> thought they blocked at the time, then I reckon they should get a
> say...  Anyway, can you peruse these issues and comment on any that
> you feel strongly about?
>
> FOR-681 Include xconf files in plugins using includes, not XPatch
> - I don't know, a blocker?

It was reported in 2005 and has not been worked on. I don't see how
this can be a blocker for the next release. Is it even relevant
anymore?

> FOR-796 Merge all view/dispatcher work into
> org.apache.forrest.plugin.internal.dispatcher and
> org.apache.forrest.themes.core
> - Thorsten's looking at this now.

Not a blocker if the goal is to get a release out. Dispatcher has been
holding back Forrest releases since 0.7, it should not block 0.9 too,
it's a whiteboard plugin.

If it is ready in time then brilliant, if not just get a release out
the door since you clearly have some momentum going here. Don't let a
"nice to have" stop that momentum. There's nothing stopping a 0.10
release a few weeks after the 0.9 if someone wants this plugin to go
into core soon (highly unlikely given how long this has sat around
unfinished but in use on peoples sites).

> FOR-911 decide content of release
> - I recommend punting on this one, we can do what we've always done.

+1

> FOR-868 add relevant notes to the "Upgrading" xdoc
> - housekeeping

+1

> FOR-1108        Dispatcher, Cocoon 2.1 and Windows
> - I dunno

Since dispatcher is a whiteboard plugin I'd say go with it anyway and
test/document that dispatcher is broken on windows. This is blocker
for dispatcher going into core, not a blocker on a 0.9 release.

> FOR-591 MaxMemory needs increasing for large document sets: Memory
> Leak with XMLFileModule
> - I'll give this another yet another attempt.

Sufficient to document for a 0.9 release, the same problem exists in
the 0.8 release.

> FOR-855 verify the license situation prior to each release
> - housekeeping

I believe Davids work with RAT fixes this issue.

> FOR-1177        where does forrest use Rhino

Not a blocker

> FOR-812 Remove dependency of projectInfo on skinconf.xml
> - maybe I don't understand it fully, but it doesn't seem like it
> should block us from a release

+1

Thanks for doing all this Tim (and others). I'm afraid this kind of
feedback is about all I will be doing towards the release - keep up
the great work.

Ross