forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: content of release [was: Re: review list of scheduled issues for 0.8 release]
Date Tue, 28 Nov 2006 04:56:45 GMT
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.


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:

> >> >- /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.
"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.


View raw message