You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Tim Williams <wi...@gmail.com> on 2006/07/11 02:49:07 UTC
content of release [was: Re: review list of scheduled issues for 0.8 release]
> It adds more fat to our release download. I suppose
> that is why it was added to the roadmap.
I don't remember if this was ever addressed or not but I recall one of
the "issues" with forrest that came up with some of our users was the
"largeness" of the download. To ease some of that, what are thoughts
on removing (from the release):
- /etc (100K)
- /main/java (140K)
- /site-author (2.89M)
- /tools/forrestbot (865K)
- /tools/eclipse (431K)
- /tools/logos (2M) (don't know what these do, so just a guess here)
Some are to get rid of some release weight and others are to avoid
some confusion (e.g. why are you shipping .java files with a release).
Thoughts?
--tim
Re: content of release [was: Re: review list of scheduled issues
for 0.8 release]
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>> David Crossley wrote:
...
> You must be in a rush. It is on the roadmap.
I'm afraid its the Ashes (Cricket to those not familiar with the term) -
you can expect lots of silly oversights periodically over the next few
weeks as I do Forrest stuff in the middle of the night here in the UK
listening to the games over there in Australia.
>> So again,
>> I wonder if the forrestbot webapp is community supported. If not, it
>> should go into whiteboard where such an issue is not a problem.
>
> This raises an important criteria that we have decided
> on before: community support.
>
> Perhaps we do need to separate the forrestbot webapp.
I'd be happy for that and I guess Tim would be happy to see a couple of
meg taken from the distribution. I've not checked, but I think it will
be a simple case of an SVN move I think the webapp is pretty much
separate from the CLI forrestbot already.
Lazy consensus is in operation.
Ross
Re: content of release [was: Re: review list of scheduled issues for 0.8 release]
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
>
> ...
>
> >>Perhaps the webapp should be moved to the whiteboard, leaving the CLI in
> >>tools and therefore the release. This would reduce the forrest bot from
> >>approx 3.7MB to approx 1.3MB.
> >
> >I don't agree with that approach. In the past we have released
> >the main forrest with known issues. Good if we can document in Jira
> >anything that we know about. Then people can see list of issues
> >that remain in the release.
>
> Hmmmm... I don't think we have ever released with a serious issue like
> reporting a successful build when it is actually a failed build. To do
> so deliberately would be a grave mistake since it would affect the vast
> majority of users using the forrestbot webapp.
That is one of the remaining issues to be considered for
the 0.8 release.
It was the new "stability" issue and the idea to hold back
a release or split up the package, that i saw a need to comment.
Yes we have released before with serious issues, e.g. there is
a memory problem with 0.7
> The stability issues I refer to is not necessarily a problem for the
> majority of users, so need not be a problem for the release. I suspect
> it is a matter of scalability (thousands of pages from 3 or 4
> distributed sources is not a typical use of Forrest).
We should add a brief note to a new Jira issue.
The "forrestbot" Jira component only lists FOR-767
> The issues are already in Jira, e.g.
> http://issues.apache.org/jira/browse/FOR-767 I can't tell you why it is
> not in the 0.8 roadmap, I guess nobody considers it important.
You must be in a rush. It is on the roadmap.
> So again,
> I wonder if the forrestbot webapp is community supported. If not, it
> should go into whiteboard where such an issue is not a problem.
This raises an important criteria that we have decided
on before: community support.
Perhaps we do need to separate the forrestbot webapp.
-David
Re: content of release [was: Re: review list of scheduled issues
for 0.8 release]
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
...
>> Perhaps the webapp should be moved to the whiteboard, leaving the CLI in
>> tools and therefore the release. This would reduce the forrest bot from
>> approx 3.7MB to approx 1.3MB.
>
> I don't agree with that approach. In the past we have released
> the main forrest with known issues. Good if we can document in Jira
> anything that we know about. Then people can see list of issues
> that remain in the release.
Hmmmm... I don't think we have ever released with a serious issue like
reporting a successful build when it is actually a failed build. To do
so deliberately would be a grave mistake since it would affect the vast
majority of users using the forrestbot webapp.
The stability issues I refer to is not necessarily a problem for the
majority of users, so need not be a problem for the release. I suspect
it is a matter of scalability (thousands of pages from 3 or 4
distributed sources is not a typical use of Forrest).
The issues are already in Jira, e.g.
http://issues.apache.org/jira/browse/FOR-767 I can't tell you why it is
not in the 0.8 roadmap, I guess nobody considers it important. So again,
I wonder if the forrestbot webapp is community supported. If not, it
should go into whiteboard where such an issue is not a problem.
Ross
Re: content of release [was: Re: review list of scheduled issues for 0.8 release]
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >Both forrestbot and forrestbar are not in the whiteboard,
> >they are in "tools"..
>
> My mistake, I'm not on my dev machine at present and didn't check the
> facts before posting. Forrestbar I have no argument with and since it is
> not in whiteboard, nobody need move it out, obviously.
>
> Forrestbot I do have a small problem with...
>
> >I have been happily using forrestbot every week to publish
> >the Forrest site, and i use it for a work-related site to
> >efficiently publish two versions of the same site. I do not
> >see any "stability" issues and i do not see any required
> >new features.
> >
> >What do you think that it lacks?
>
> The forrestbot CLI works just fine for me as well, it is the webapp that
> has problems. The two critical issues are that it reports the wrong
> status of the last build, and is unstable in that it needs regular
> rebooting (I think this is a scalability problem, but have not had the
> time to investigate fully)
>
> Perhaps the webapp should be moved to the whiteboard, leaving the CLI in
> tools and therefore the release. This would reduce the forrest bot from
> approx 3.7MB to approx 1.3MB.
I don't agree with that approach. In the past we have released
the main forrest with known issues. Good if we can document in Jira
anything that we know about. Then people can see list of issues
that remain in the release.
-David
Re: content of release [was: Re: review list of scheduled issues
for 0.8 release]
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Both forrestbot and forrestbar are not in the whiteboard,
> they are in "tools"..
My mistake, I'm not on my dev machine at present and didn't check the
facts before posting. Forrestbar I have no argument with and since it is
not in whiteboard, nobody need move it out, obviously.
Forrestbot I do have a small problem with...
> I have been happily using forrestbot every week to publish
> the Forrest site, and i use it for a work-related site to
> efficiently publish two versions of the same site. I do not
> see any "stability" issues and i do not see any required
> new features.
>
> What do you think that it lacks?
The forrestbot CLI works just fine for me as well, it is the webapp that
has problems. The two critical issues are that it reports the wrong
status of the last build, and is unstable in that it needs regular
rebooting (I think this is a scalability problem, but have not had the
time to investigate fully)
Perhaps the webapp should be moved to the whiteboard, leaving the CLI in
tools and therefore the release. This would reduce the forrest bot from
approx 3.7MB to approx 1.3MB.
Ross
Re: content of release [was: Re: review list of scheduled issues for 0.8 release]
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> Thorsten Scherler wrote:
> >
> >Regarding the whiteboard and seeing that the dispatcher has gained wider
> >community support, I think we should either move the dispatcher out of
> >the whiteboard or include the whiteboard into the release.
>
> I'm still of the opinion that nothing in whiteboard goes into the
> release. If something is stable and community oriented enough to warrant
> going into the release then we should attend to it as part of the 0.8
> release cycle.
>
> Candidates for migration from whiteboard are, IMHO:
>
> - dispatcher
> - forrestbot
> - forrestbar
>
> Dispatcher looks like a given to me, in fact I've called for someone to
> bring it out of whiteboard many times, if the devs active on that code
> now agree it is ready then this is great news.
>
> Forrestbot is, in my opinion, not stable or complete enough for release
> as a user tool (althoug I do have it running in a couple of locations).
> David points out that we have "released" it before, but this is only as
> a part of whiteboard, I don't really see that as a release since
> whiteboard has always had the status of experimental and potentially
> unsupported code.
Both forrestbot and forrestbar are not in the whiteboard,
they are in "tools"..
I have been happily using forrestbot every week to publish
the Forrest site, and i use it for a work-related site to
efficiently publish two versions of the same site. I do not
see any "stability" issues and i do not see any required
new features.
What do you think that it lacks?
-David
> Forrest bar seems very popular with devs and is a very useful tool when
> trying to empower new devs. We are missing an opportunity having it
> hidden away in whiteboard. Someone should bring it out (sorry, not me,
> too little time right now).
>
> Ross
Re: content of release [was: Re: review list of scheduled issues
for 0.8 release]
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Tue, 2006-11-28 at 18:54 +1100, David Crossley wrote:
>> Tim Williams wrote:
>>> Ross Gardler wrote:
>>>> David Crossley wrote:
>>>>> What about my proposal above to have combined binary/source
>>>>> release (like we do now) except only have separate packages
>>>>> of specific parts, i.e. not everything.
>>> I'm not sure how that'd be done?
>> Neither am i.
>>
>> If you are talking about the mechanics of it, see below.
>> We discussed some the specific parts in the other replies.
>>
>> See the "release-dist" Ant target in main/build.xml
>>
>> I presume that we get it to include only certain parts of
>> the trunk into separate packages. We have things well-separated,
>> so it should be simple. FLW.
>>
>> We also need to create LICENSE.txt and NOTICE.txt in the
>> top of each package. Should be okay with Ant.
>
> As I see it, it should not be hard to package the release different. The
> question is whether you want to package them apart, e.g. forrestbot
> without forrest.
>
> That leaves us with packages like:
> * forrest-core
> * forrestbot
> * eclipse-tool
> * forrestbar
>
> Then the packages can be downloaded separately, similar like they do it
> with tomcat and the admin interface.
>
> Regarding the whiteboard and seeing that the dispatcher has gained wider
> community support, I think we should either move the dispatcher out of
> the whiteboard or include the whiteboard into the release.
I'm still of the opinion that nothing in whiteboard goes into the
release. If something is stable and community oriented enough to warrant
going into the release then we should attend to it as part of the 0.8
release cycle.
Candidates for migration from whiteboard are, IMHO:
- dispatcher
- forrestbot
- forrestbar
Dispatcher looks like a given to me, in fact I've called for someone to
bring it out of whiteboard many times, if the devs active on that code
now agree it is ready then this is great news.
Forrestbot is, in my opinion, not stable or complete enough for release
as a user tool (althoug I do have it running in a couple of locations).
David points out that we have "released" it before, but this is only as
a part of whiteboard, I don't really see that as a release since
whiteboard has always had the status of experimental and potentially
unsupported code.
Forrest bar seems very popular with devs and is a very useful tool when
trying to empower new devs. We are missing an opportunity having it
hidden away in whiteboard. Someone should bring it out (sorry, not me,
too little time right now).
Ross
Re: content of release [was: Re: review list of scheduled issues
for 0.8 release]
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Tue, 2006-11-28 at 18:54 +1100, David Crossley wrote:
> Tim Williams wrote:
> > Ross Gardler wrote:
> > >David Crossley wrote:
> > >>
> > >> What about my proposal above to have combined binary/source
> > >> release (like we do now) except only have separate packages
> > >> of specific parts, i.e. not everything.
> >
> > I'm not sure how that'd be done?
>
> Neither am i.
>
> If you are talking about the mechanics of it, see below.
> We discussed some the specific parts in the other replies.
>
> See the "release-dist" Ant target in main/build.xml
>
> I presume that we get it to include only certain parts of
> the trunk into separate packages. We have things well-separated,
> so it should be simple. FLW.
>
> We also need to create LICENSE.txt and NOTICE.txt in the
> top of each package. Should be okay with Ant.
As I see it, it should not be hard to package the release different. The
question is whether you want to package them apart, e.g. forrestbot
without forrest.
That leaves us with packages like:
* forrest-core
* forrestbot
* eclipse-tool
* forrestbar
Then the packages can be downloaded separately, similar like they do it
with tomcat and the admin interface.
Regarding the whiteboard and seeing that the dispatcher has gained wider
community support, I think we should either move the dispatcher out of
the whiteboard or include the whiteboard into the release.
salu2
>
> -David
Re: content of release [was: Re: review list of scheduled issues for 0.8 release]
Posted by David Crossley <cr...@apache.org>.
Tim Williams wrote:
> Ross Gardler wrote:
> >David Crossley wrote:
> >>
> >> What about my proposal above to have combined binary/source
> >> release (like we do now) except only have separate packages
> >> of specific parts, i.e. not everything.
>
> I'm not sure how that'd be done?
Neither am i.
If you are talking about the mechanics of it, see below.
We discussed some the specific parts in the other replies.
See the "release-dist" Ant target in main/build.xml
I presume that we get it to include only certain parts of
the trunk into separate packages. We have things well-separated,
so it should be simple. FLW.
We also need to create LICENSE.txt and NOTICE.txt in the
top of each package. Should be okay with Ant.
-David
Re: content of release [was: Re: review list of scheduled issues for 0.8 release]
Posted by Tim Williams <wi...@gmail.com>.
On 11/27/06, Ross Gardler <rg...@apache.org> wrote:
> David Crossley wrote:
> > Ross Gardler wrote:
>
> ...
>
> >>
> >>> We also have stuff in whiteboard to consider.
> >> Whiteboard should be a separate download.
> >
> > Why all of it? Is that all targetted at users and ready
> > for them? The Forrest PMC would need to vote on its release
> > as a package.
>
> Whiteboard is, by definition, experimental code that does not yet have a
> community. Making it easy for users to access it opens us to support
> requests. We should be encouraging technical users to dip there feet in.
>
> So, my preference would be to not provide a release for anything in
> whiteboard. Only make it available via SVN. I know this will be greeted
> with some resistence, and I'm sure much of it will be supported with
> valid argument. I'm not insisting on this, just thinking aloud.
+1 on only making it available via SVN. We don't endorse it as a PMC.
Most folks who might have a peek at the whiteboard have probably
already decided to get forrest via svn anyway.
> ...
>
> >> Having said all this the real problem with our size is the jars we
> >> bundle not Forrest itself, these account for 40Mb according to "du -h
> >> lib" trimming a further 1 or two meg by dropping source is kind of
> >> irrelevant most people will have a brew during download whether it is
> >> 42Mb or 44Mb.
> >
> > Sounds like a task for Ivy. We also have some duplicate jars
> > at various other places in our SVN.
>
> Yes I'll call the vote on the use of IVY when I return home (later this
> week).
This is indeed a problem and I'm cool with looking into Ivy as a
potential solution; however, it is not *the* real problem. There are
many "real" problems that we are discussing here. Fix this one and
the additional 2.9Mb from the site-author might be the next optional
bloat. Fix that one and the *.java files might be the next priority.
They're all real though.
> ...
>
> >>>> The src release should still include eveything.
> >>> Are you still wanting that? It would be huge.
> >> Everything except whiteboard?
> >
> > What about my proposal above to have combined binary/source
> > release (like we do now) except only have separate packages
> > of specific parts, i.e. not everything.
I'm not sure how that'd be done?
--tim
Re: content of release [was: Re: review list of scheduled issues
for 0.8 release]
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
...
>>
>>> We also have stuff in whiteboard to consider.
>> Whiteboard should be a separate download.
>
> Why all of it? Is that all targetted at users and ready
> for them? The Forrest PMC would need to vote on its release
> as a package.
Whiteboard is, by definition, experimental code that does not yet have a
community. Making it easy for users to access it opens us to support
requests. We should be encouraging technical users to dip there feet in.
So, my preference would be to not provide a release for anything in
whiteboard. Only make it available via SVN. I know this will be greeted
with some resistence, and I'm sure much of it will be supported with
valid argument. I'm not insisting on this, just thinking aloud.
...
>> Having said all this the real problem with our size is the jars we
>> bundle not Forrest itself, these account for 40Mb according to "du -h
>> lib" trimming a further 1 or two meg by dropping source is kind of
>> irrelevant most people will have a brew during download whether it is
>> 42Mb or 44Mb.
>
> Sounds like a task for Ivy. We also have some duplicate jars
> at various other places in our SVN.
Yes I'll call the vote on the use of IVY when I return home (later this
week).
...
>>>> The src release should still include eveything.
>>> Are you still wanting that? It would be huge.
>> Everything except whiteboard?
>
> What about my proposal above to have combined binary/source
> release (like we do now) except only have separate packages
> of specific parts, i.e. not everything.
Sure, if that's what people want, see my comments above about excluding
Whiteboard. When it comes down to it I'm not going to be building the
release, so whatever someone asks me to test I'll go with.
Ross
Re: content of release [was: Re: review list of scheduled issues for 0.8 release]
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
> >>Tim Williams wrote:
> >>>David Crossley wrote:
> >>>>[about Eclipse plugin tool ...]
> >>>>It adds more fat to our release download. I suppose
> >>>>that is why it was added to the roadmap.
> >>>I don't remember if this was ever addressed or not but I recall one of
> >>>the "issues" with forrest that came up with some of our users was the
> >>>"largeness" of the download. To ease some of that, what are thoughts
> >>>on removing (from the release):
> >>>
> >>>- /etc (100K)
> >>>- /main/java (140K)
> >>>- /site-author (2.89M)
> >
> >One reason for including this is so that they have local docs.
> >This also enables people to easily tweak and send a patch. Hmmpf.
> >Another reason is probably so that we release the source.
> >Perhaps we should release a separate "docs" package.
>
> It should be fairly easy to have a compromise position. For example, can
> we separate the 0.8 docs and release them, leaving the 0.6 and 0.7 docs
> online only. Similarly we can trim the plugin docs.
Not easily.
> I'm not sure what impact this will have on the size of the download but
> it must be significant given that all together is 2.89M by Tims
> evaluation above.
>
> >>>- /tools/forrestbot (865K)
> >
> >That is a necessary tool. IMO should still be included
> >or it should be released as a separate package.
>
> +0
>
> >>>- /tools/eclipse (431K)
> >
> >Not sure how you calculate those numbers. I get 17Mb.
> >IMO this should not be included.
>
> +0
>
> >>>- /tools/logos (2M) (don't know what these do, so just a guess here)
> >
> >There is a thread in the dev archives from me about this.
> >IMO should not be included.
>
> +0
>
> >We also have stuff in whiteboard to consider.
>
> Whiteboard should be a separate download.
Why all of it? Is that all targetted at users and ready
for them? The Forrest PMC would need to vote on its release
as a package.
> >>>Some are to get rid of some release weight and others are to avoid
> >>>some confusion (e.g. why are you shipping .java files with a release).
> >
> >What we released in the past is a combined source/binary release.
> >The idea was that they would have everything required to
> >dive in and tweak things.
> >
> >Why are *.java included? AFAIK we release open source
> >software, so we include our source. The pre-built binary
> >forrest.jar is included for convenience to users.
>
> +1 for including the source (including docs since this is a pretty good
> example of a major content object)
>
> >>I would like to see the binary distribution only include Forrest core
> >>and the necessary tools. No plugins, no whiteboard, no forestbot, no
> >>eclipse etc.
>
> I agree to all that *except* we should include source. In this I am
> assuming that the trimmed sources (see above comments about docs) will
> bring the size down a fair amount. If the source package is large then
> I'd not object to separate source/binary releases.
>
> Having said all this the real problem with our size is the jars we
> bundle not Forrest itself, these account for 40Mb according to "du -h
> lib" trimming a further 1 or two meg by dropping source is kind of
> irrelevant most people will have a brew during download whether it is
> 42Mb or 44Mb.
Sounds like a task for Ivy. We also have some duplicate jars
at various other places in our SVN.
> >Does the following make sense to have separate combined
> >source/binary packages?
> >
> >* "apache-forrest-core" which includes everything under "main"
> >and "bin" and "tools/ant" and "tools/jetty" and includes a
> >pre-built forrest.jar file.
> >Does it also need the plugin descriptors?
>
> Plugin descriptors are retrieved from the web if not available locally
> (needs testing in case my memory is playing tricks on me).
Probably should include them in the release so that their
first experience can be offline.
> >* "apache-forrest-forrestbot" includes its source and a pre-built binary.
> >
> >* "apache-forrest-plugins" includes all plugins (both core and
> >whiteboard) at the time of the "core" release, plus pre-built
> >binaries for those plugins that need it.
>
> OK
>
> >>Plugins are auto downloaded on the first run anyway (we should provide a
> >>separate plugins package though).
> >
> >Actually we have some problems with the way we have been
> >"releasing" plugins. Basically the PMC needs to vote on every
> >package that is intended for use beyond the developers.
> >
> >Not sure in which thread we should discuss this aspect. It was
> >raised once before here:
> >http://marc.theaimsgroup.com/?l=forrest-dev&m=115398481306651
> >and see the notes at http://apache.org/dev/release.html#what
>
> There is an issue for this somewhere (I think) - can't search now,
> working with offline email - sorry.
Would someone please find this.
> >Also the plugins should be on the mirror system, rather than
> >being provided from w.a.o website. Not sure how we can fix that.
> >Probably don't need to do this immediately, but certainly
> >before Forrest gets too many users.
>
> Assuming descriptors are retrieved from the web then we can make this
> change later since the descriptor will say where to download from.
>
> However, we should really be using something like Ivy to manage our
> plugin downloads and therefore do away with our "proprietary"
> descriptors (not a 0.8 issue)
That sounds great.
> >>The src release should still include eveything.
> >
> >Are you still wanting that? It would be huge.
>
> Everything except whiteboard?
What about my proposal above to have combined binary/source
release (like we do now) except only have separate packages
of specific parts, i.e. not everything.
-David
> >By the way, i don't have the time to follow through on this.
> >I can help, but i cannot be the main man.
>
> Similarly, I'm not likely to find the time to trim 0.8. Of course, I'm
> willing to give my opinion on things, but given I have no time you won't
> see any +/-1's from me on these issues. However, I will assist with
> building, signing, testing release distributions once they are ready.
>
> Ross
Re: content of release [was: Re: review list of scheduled issues
for 0.8 release]
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>> Tim Williams wrote:
>>> David Crossley wrote:
>>>> [about Eclipse plugin tool ...]
>>>> It adds more fat to our release download. I suppose
>>>> that is why it was added to the roadmap.
>>> I don't remember if this was ever addressed or not but I recall one of
>>> the "issues" with forrest that came up with some of our users was the
>>> "largeness" of the download. To ease some of that, what are thoughts
>>> on removing (from the release):
>>>
>>> - /etc (100K)
>>> - /main/java (140K)
>>> - /site-author (2.89M)
>
> One reason for including this is so that they have local docs.
> This also enables people to easily tweak and send a patch. Hmmpf.
> Another reason is probably so that we release the source.
> Perhaps we should release a separate "docs" package.
It should be fairly easy to have a compromise position. For example, can
we separate the 0.8 docs and release them, leaving the 0.6 and 0.7 docs
online only. Similarly we can trim the plugin docs.
I'm not sure what impact this will have on the size of the download but
it must be significant given that all together is 2.89M by Tims
evaluation above.
>>> - /tools/forrestbot (865K)
>
> That is a necessary tool. IMO should still be included
> or it should be released as a separate package.
+0
>>> - /tools/eclipse (431K)
>
> Not sure how you calculate those numbers. I get 17Mb.
> IMO this should not be included.
+0
>>> - /tools/logos (2M) (don't know what these do, so just a guess here)
>
> There is a thread in the dev archives from me about this.
> IMO should not be included.
+0
> We also have stuff in whiteboard to consider.
Whiteboard should be a separate download.
>>> Some are to get rid of some release weight and others are to avoid
>>> some confusion (e.g. why are you shipping .java files with a release).
>
> What we released in the past is a combined source/binary release.
> The idea was that they would have everything required to
> dive in and tweak things.
>
> Why are *.java included? AFAIK we release open source
> software, so we include our source. The pre-built binary
> forrest.jar is included for convenience to users.
+1 for including the source (including docs since this is a pretty good
example of a major content object)
>> I would like to see the binary distribution only include Forrest core
>> and the necessary tools. No plugins, no whiteboard, no forestbot, no
>> eclipse etc.
I agree to all that *except* we should include source. In this I am
assuming that the trimmed sources (see above comments about docs) will
bring the size down a fair amount. If the source package is large then
I'd not object to separate source/binary releases.
Having said all this the real problem with our size is the jars we
bundle not Forrest itself, these account for 40Mb according to "du -h
lib" trimming a further 1 or two meg by dropping source is kind of
irrelevant most people will have a brew during download whether it is
42Mb or 44Mb.
> Does the following make sense to have separate combined
> source/binary packages?
>
> * "apache-forrest-core" which includes everything under "main"
> and "bin" and "tools/ant" and "tools/jetty" and includes a
> pre-built forrest.jar file.
> Does it also need the plugin descriptors?
Plugin descriptors are retrieved from the web if not available locally
(needs testing in case my memory is playing tricks on me).
> * "apache-forrest-forrestbot" includes its source and a pre-built binary.
>
> * "apache-forrest-plugins" includes all plugins (both core and
> whiteboard) at the time of the "core" release, plus pre-built
> binaries for those plugins that need it.
OK
>> Plugins are auto downloaded on the first run anyway (we should provide a
>> separate plugins package though).
>
> Actually we have some problems with the way we have been
> "releasing" plugins. Basically the PMC needs to vote on every
> package that is intended for use beyond the developers.
>
> Not sure in which thread we should discuss this aspect. It was
> raised once before here:
> http://marc.theaimsgroup.com/?l=forrest-dev&m=115398481306651
> and see the notes at http://apache.org/dev/release.html#what
There is an issue for this somewhere (I think) - can't search now,
working with offline email - sorry.
> Also the plugins should be on the mirror system, rather than
> being provided from w.a.o website. Not sure how we can fix that.
> Probably don't need to do this immediately, but certainly
> before Forrest gets too many users.
Assuming descriptors are retrieved from the web then we can make this
change later since the descriptor will say where to download from.
However, we should really be using something like Ivy to manage our
plugin downloads and therefore do away with our "proprietary"
descriptors (not a 0.8 issue)
>> The src release should still include eveything.
>
> Are you still wanting that? It would be huge.
Everything except whiteboard?
> By the way, i don't have the time to follow through on this.
> I can help, but i cannot be the main man.
Similarly, I'm not likely to find the time to trim 0.8. Of course, I'm
willing to give my opinion on things, but given I have no time you won't
see any +/-1's from me on these issues. However, I will assist with
building, signing, testing release distributions once they are ready.
Ross
Re: content of release [was: Re: review list of scheduled issues
for 0.8 release]
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
> David Crossley wrote:
>
>> One reason for including this is so that they have local docs.
>
> I really like projects that come with local docs so you don't have to
> start wondering if you have picked the right docs for a certain
> release.
>
> And 3 MB doesn't see such a high penalty, does it?
I too like local docs, and it doesn't need to be anything like 3MB if we
trim out docs for past releases.
Ross
Re: content of release [was: Re: review list of scheduled issues for 0.8 release]
Posted by Ferdinand Soethe <fe...@apache.org>.
David Crossley wrote:
> One reason for including this is so that they have local docs.
I really like projects that come with local docs so you don't have to
start wondering if you have picked the right docs for a certain
release.
And 3 MB doesn't see such a high penalty, does it?
--
Ferdinand Soethe
Re: content of release [was: Re: review list of scheduled issues for 0.8 release]
Posted by David Crossley <cr...@apache.org>.
Tim Williams wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
> >> Tim Williams wrote:
> >> >David Crossley wrote:
> >> >>
> >> >> [about Eclipse plugin tool ...]
> >> >>It adds more fat to our release download. I suppose
> >> >>that is why it was added to the roadmap.
> >> >
> >> >I don't remember if this was ever addressed or not but I recall one of
> >> >the "issues" with forrest that came up with some of our users was the
> >> >"largeness" of the download. To ease some of that, what are thoughts
> >> >on removing (from the release):
> >> >
> >> >- /etc (100K)
> >> >- /main/java (140K)
> >> >- /site-author (2.89M)
> >
> >One reason for including this is so that they have local docs.
> >This also enables people to easily tweak and send a patch. Hmmpf.
> >Another reason is probably so that we release the source.
> >Perhaps we should release a separate "docs" package.
>
> Still a lot of bloat for an optional piece. When I go to the docs for
> example, I go to f.a.o for them - if someone wants them locally that
> should (IMO) be separately.
Okay.
This might explain why (speaking generally) we cannot even get
committers to fix the docs as they read them.
> We ask for patches via svn so they'll need
> to get the docs separately anyway likely.
We prefer patches against svn trunk, but will accept anything:
http://forrest.apache.org/contrib.html#patch
> >> >- /tools/forrestbot (865K)
> >
> >That is a necessary tool. IMO should still be included
> >or it should be released as a separate package.
> >
> >> >- /tools/eclipse (431K)
> >
> >Not sure how you calculate those numbers. I get 17Mb.
> >IMO this should not be included.
>
> Seems subjective to keep forrestbot and dump eclipse. Neither work
> well for me, so I'm inclined to say drop them both from the release.
For me, the point is that we have released forrestbot in the past
and some people have come to depend on it. Its license situation
has already been attended to. Various Forrest developers have worked
on it over the years. It works fine for me and i gather that
some other projects use it. You have some issues, but they have not
been followed through sufficiently.
We have not yet ever released the Eclipse plugin, so there
is plenty of license stuff to investigate. Also there is lots
of duplicated jars. Also IIRC no Forrest developers have worked
on it apart from applying the GSoC patches.
I am looking for ways to trim down the main Forrest release.
When i have suggested "IMO should not be included" i meant
"not included in the core release". If people want these tools
released as separate packages, then that is possible.
> > > >- /tools/logos (2M) (don't know what these do, so just a guess here)
> >
> >There is a thread in the dev archives from me about this.
> >IMO should not be included.
> >
> >We also have stuff in whiteboard to consider.
> >
> >> >Some are to get rid of some release weight and others are to avoid
> >> >some confusion (e.g. why are you shipping .java files with a release).
> >
> >What we released in the past is a combined source/binary release.
> >The idea was that they would have everything required to
> >dive in and tweak things.
> >
> >Why are *.java included? AFAIK we release open source
> >software, so we include our source. The pre-built binary
> >forrest.jar is included for convenience to users.
>
> Huh? That's not right, open source means the source is freely
> available rather than shipped with every release. Look around at our
> peers (httpd, ant, tomcat) - none that I see ship .java files with a
> release. I disagree with your (this-follows-that) conclusion here.
Careful, some projects are in the C programming language.
Some projects do releases differently, but that doesn't mean that
they are correct.
http://apache.org/dev/release.html#what
"All releases are in the form of the source materials needed to make changes to the software being released. In some cases, binary/bytecode packages are also produced as a convenience to users that might not have the appropriate tools to build a compiled version of the source."
Regarding the situation with Forrest: In the past we have
delivered a single release package which contains the source,
the build files, the sitemaps and stylesheets, a pre-built
binary jar file as a convenience. They can make changes,
re-build, and if they choose, send patches, get involved.
My proposal is to continue doing that, but separate it
into specific packages for specific sections.
-David
Re: content of release [was: Re: review list of scheduled issues for 0.8 release]
Posted by Tim Williams <wi...@gmail.com>.
On 11/23/06, David Crossley <cr...@apache.org> wrote:
> Ross Gardler wrote:
> > Tim Williams wrote:
> > >David Crossley wrote:
> > >>
> > >> [about Eclipse plugin tool ...]
> > >>It adds more fat to our release download. I suppose
> > >>that is why it was added to the roadmap.
> > >
> > >I don't remember if this was ever addressed or not but I recall one of
> > >the "issues" with forrest that came up with some of our users was the
> > >"largeness" of the download. To ease some of that, what are thoughts
> > >on removing (from the release):
> > >
> > >- /etc (100K)
> > >- /main/java (140K)
> > >- /site-author (2.89M)
>
> One reason for including this is so that they have local docs.
> This also enables people to easily tweak and send a patch. Hmmpf.
> Another reason is probably so that we release the source.
> Perhaps we should release a separate "docs" package.
Still a lot of bloat for an optional piece. When I go to the docs for
example, I go to f.a.o for them - if someone wants them locally that
should (IMO) be separately. We ask for patches via svn so they'll need
to get the docs separately anyway likely.
> > >- /tools/forrestbot (865K)
>
> That is a necessary tool. IMO should still be included
> or it should be released as a separate package.
>
> > >- /tools/eclipse (431K)
>
> Not sure how you calculate those numbers. I get 17Mb.
> IMO this should not be included.
Seems subjective to keep forrestbot and dump eclipse. Neither work
well for me, so I'm inclined to say drop them both from the release.
> > >- /tools/logos (2M) (don't know what these do, so just a guess here)
>
> There is a thread in the dev archives from me about this.
> IMO should not be included.
>
> We also have stuff in whiteboard to consider.
>
> > >Some are to get rid of some release weight and others are to avoid
> > >some confusion (e.g. why are you shipping .java files with a release).
>
> What we released in the past is a combined source/binary release.
> The idea was that they would have everything required to
> dive in and tweak things.
>
> Why are *.java included? AFAIK we release open source
> software, so we include our source. The pre-built binary
> forrest.jar is included for convenience to users.
Huh? That's not right, open source means the source is freely
available rather than shipped with every release. Look around at our
peers (httpd, ant, tomcat) - none that I see ship .java files with a
release. I disagree with your (this-follows-that) conclusion here.
--tim
Re: content of release [was: Re: review list of scheduled issues for 0.8 release]
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> Tim Williams wrote:
> >David Crossley wrote:
> >>
> >> [about Eclipse plugin tool ...]
> >>It adds more fat to our release download. I suppose
> >>that is why it was added to the roadmap.
> >
> >I don't remember if this was ever addressed or not but I recall one of
> >the "issues" with forrest that came up with some of our users was the
> >"largeness" of the download. To ease some of that, what are thoughts
> >on removing (from the release):
> >
> >- /etc (100K)
> >- /main/java (140K)
> >- /site-author (2.89M)
One reason for including this is so that they have local docs.
This also enables people to easily tweak and send a patch. Hmmpf.
Another reason is probably so that we release the source.
Perhaps we should release a separate "docs" package.
> >- /tools/forrestbot (865K)
That is a necessary tool. IMO should still be included
or it should be released as a separate package.
> >- /tools/eclipse (431K)
Not sure how you calculate those numbers. I get 17Mb.
IMO this should not be included.
> >- /tools/logos (2M) (don't know what these do, so just a guess here)
There is a thread in the dev archives from me about this.
IMO should not be included.
We also have stuff in whiteboard to consider.
> >Some are to get rid of some release weight and others are to avoid
> >some confusion (e.g. why are you shipping .java files with a release).
What we released in the past is a combined source/binary release.
The idea was that they would have everything required to
dive in and tweak things.
Why are *.java included? AFAIK we release open source
software, so we include our source. The pre-built binary
forrest.jar is included for convenience to users.
> I did a similar analysis before the 0.6 release and before the 0.7
> release. We've ever had consensus to remove other stuff, I'm really not
> sure why.
Perhaps not followed through. I don't remember such
discussion. Can anyone find it in the archives?
> I would like to see the binary distribution only include Forrest core
> and the necessary tools. No plugins, no whiteboard, no forestbot, no
> eclipse etc.
Does the following make sense to have separate combined
source/binary packages?
* "apache-forrest-core" which includes everything under "main"
and "bin" and "tools/ant" and "tools/jetty" and includes a
pre-built forrest.jar file.
Does it also need the plugin descriptors?
* "apache-forrest-forrestbot" includes its source and a pre-built binary.
* "apache-forrest-plugins" includes all plugins (both core and
whiteboard) at the time of the "core" release, plus pre-built
binaries for those plugins that need it.
> Plugins are auto downloaded on the first run anyway (we should provide a
> separate plugins package though).
Actually we have some problems with the way we have been
"releasing" plugins. Basically the PMC needs to vote on every
package that is intended for use beyond the developers.
Not sure in which thread we should discuss this aspect. It was
raised once before here:
http://marc.theaimsgroup.com/?l=forrest-dev&m=115398481306651
and see the notes at http://apache.org/dev/release.html#what
Also the plugins should be on the mirror system, rather than
being provided from w.a.o website. Not sure how we can fix that.
Probably don't need to do this immediately, but certainly
before Forrest gets too many users.
> The src release should still include eveything.
Are you still wanting that? It would be huge.
--------- oOo ---------
http://issues.apache.org/jira/browse/FOR-911
"decide content of release"
--------- oOo ---------
By the way, i don't have the time to follow through on this.
I can help, but i cannot be the main man.
-David
Re: content of release [was: Re: review list of scheduled issues
for 0.8 release]
Posted by Ross Gardler <rg...@apache.org>.
Tim Williams wrote:
>> It adds more fat to our release download. I suppose
>> that is why it was added to the roadmap.
>
>
> I don't remember if this was ever addressed or not but I recall one of
> the "issues" with forrest that came up with some of our users was the
> "largeness" of the download. To ease some of that, what are thoughts
> on removing (from the release):
>
> - /etc (100K)
> - /main/java (140K)
> - /site-author (2.89M)
> - /tools/forrestbot (865K)
> - /tools/eclipse (431K)
> - /tools/logos (2M) (don't know what these do, so just a guess here)
>
> Some are to get rid of some release weight and others are to avoid
> some confusion (e.g. why are you shipping .java files with a release).
>
> Thoughts?
I did a similar analysis before the 0.6 release and before the 0.7
release. We've ever had consensus to remove other stuff, I'm really not
sure why.
I would like to see the binary distribution only include Forrest core
and the necessary tools. No plugins, no whiteboard, no forestbot, no
eclipse etc.
Plugins are auto downloaded on the first run anyway (we should provide a
separate plugins package though).
The src release should still include eveything.
Ross