On Nov 7, 2006, at 7:16 PM, David Jencks wrote:
My objection to putting the jee5 work into a branch is that it's
not a branch! It is currently and IMO will always remain
additional code that can happily run side by side with all our
current code. Creating the jee5 workspace is not going to involve
copying any existing geronimo server branch: its going to involve
adding new modules for new functionality. After reading ken's
comments I agree that keeping it in the sandbox carries an unwanted
implication that it's not ready for prime time.
I agree with David that we should not be putting a "sparse" branch in
server/branches/.
I don't necessarily agree with "will always remain additional code
that can happily run side by side with all our current code", but I
think that can be a future discussion...
IMO, "sandbox" development does not imply "toy". It does imply
"temporary location" or "experimental work" and sometimes "toy". If
modules, configs, and assemblies can be built reliably from a
sandbox, then I don't think that the fact that the code is in
"sandbox" is a significant barrier. The code will be important, if
those working on it make it so...
If there's too much stigma associated with sandbox, then let's
establish a convention for hosting "sparse" branches (e.g. server/
sparse/jee5 or server/sparse/jpa, etc). This all assumes that a
sparse development branch is a viable solution...
Seems useful to review the options:
1) Create a full branch (e.g. server/branches/jee5) which is a copy
of current trunk. And develop there. Once server/branches/1.2 has
been created. server/branches/jee5 could be merged onto trunk. The
problem with this approach is that the overhead of merging vs.
problem resolution. Either you work diligently to keep the codebases
in sync, or you potentially debug problems on two codebases, and pay
merge costs later...
2) Develop in a sparse source tree. The source tree only contains the
new code that is being developed. The hope is that this reduces the
overhead of merging changes. However, it will also complicate the
build process -- it seems that Joe has been having problems building
using this technique.
3) Create server/branches/1.2, now. This seems pretty much equivalent
to 1). Similar merging concerns... Most changes made to branches/1.2
will require merging onto trunk.
If people can make reasonable progress on jee5 using 2), then that
seems as close as we'll get to a win-win...
--kevan
