David Crossley wrote:
Ross Gardler wrote:
David Crossley wrote:
Ross Gardler wrote:
I've not thought through the implications of this. I'm pretty sure that
moving tools out is a good idea (notice I suggest a tools subdirectory
when moving eclipse, that was for a reason ;-) feel free to rubbish the
idea though (or even agree with it ;-)
I don't yet see what we gain by doing this, other than
people can checkout certain parts separately.
My thinking is that we move all plugins code out of core. Most devs are
not interested in most of the plugins, yet they have to checkout
everything. Similarly, most devs are not interested in whiteboard or tools.
There are a lot of people interested in whiteboard
at the moment ;-)
Very good point (I assume you mean views).
When we consider things like full docbook support in a plugin we will
have lots of XSL, DTD etc. from the Docbook project. This will be a
pretty large plugin, others may also get pretty large.
DocBook is not a good example, because we decided to
develop a download system for such cases. But yes
some plugins will grow large because of additional
jars, or large content like the gallery plugin.
By extracting the plugins, tools, whiteboard etc we enable devs to
checkout just the core stuff and any particular parts they want. Hence
checkout (and subsequent "svn status" and similar commands) happen
quicker. Using svn:external we can still provide a single checkout for
those developers who want everything.
That is what causes me confusion. When *any* developer
does an 'svn checkout' of trunk, then they get all the
pieces anyway. So no benefit regarding volume of data.
Am i missing something?
It depends how it is set up. We can choose to have *some*
plugins/whiteboard etc. in the "trunk" (i.e. forrest-core) checkout. It
need not be all. We can also provide different checkouts that contain
different sets of tools and plugins (this really is going too far though
I think).
Using views as an example. It could have started life as a set of
plugins in whiteboard *without* an svn:external in forrest-core. Thus it
doesn't get checked out by most devs. However, once it becomes
reasonably stable and people are taking an insterest we can add an
svn:external to forrest-core. SO all devs start getting it.
One benefit that i do see is that those pieces can
have separate release cycles and can have branches.
That also adds a lot of work at release time, but
it is a lot of work anyway.
Well plugins can already have their own release cycle. Whiteboard items
may never be formally released, but they do have "soft release" by using
svn:external to bring them into core.
What additional work does this add at release time though? If it makes
release management harder we have to balance that against any percieved
development benefits. I'm still undecided, this could result in
splitting things up and dividing the community then again, it may make
it easier for people to start development.
Similarly, some devs are not interested in core, but would like to work
on docs or on, for example, the OOo plugin. These devs would be able to
work on them without having to checkout the full Forrest svn.
That is where i can certainly see benefit.
However, it would be preferable that developers
work with the current core. I suppose if we have
proper and automated testing, then we will discover
inconsistencies.
Plugins can have a different release cycle. Currently there is only one
plugin that has an SVN head version that requires 0.8-dev Plugins should
continue to support the earliest version of Forrest it is possible for
them to support. Therefore there is no need for people to work against
the current core.
However, I do agree that this raises a problem with automated testing.
We have a level of this in that the test target of plugins is run
whenever a plugin is deployed. However, this has problems in that the
test may not be complete (i.e. not all features are present) and it may
not be tested against the Forrest version claimed to be supported. (I'll
raise an issue about this).
Ross
