On May 30, 2005, at 11:22 AM, Geir Magnusson Jr. wrote:
On May 28, 2005, at 12:38 PM, Dain Sundstrom wrote:
I just read through the long "Module restructure" thread, and it
to me is seems like many people are talking about how we break
Geronimo into subprojects without using the word subproject.
That may be where it went to out of confusion, but I think the
original point was how to get organized so we can have a stable
tree that is what those of us interested in a sable certified
release work in while other work can continue.
Nice. I'm interested in a stable tree for certification. I just want
to avoid unnecessary complexity and all of the module restructuring
plans so far seem like a svn merge nightmare
The goals of the "Module restructure" thread seem to be:
1) allow modules to branch to unstable without requiring the
geronimo trunk to take unstable code
I would have gone the other way - branch out the stable and let
work continue in trunk, and loony things go off to a sandbox.
Agreed. That was a typo, but you got the meaning.
2) allow modules to have independent release cycles so they don't
have to wait for geronimo trunk
Regardless what we call it, that is a sub project. I think we
should bite the bullet and talk about what sets of functionality
make sense as a subproject. For example, I think there is a
demonstrated desire to have a TX/JCA subproject in Geronimo.
The problem with trying to force the language to be "subproject"
rather than "module" is that "subproject" is a loaded word at
apache with different meaning - in that it has historically, from
jakarta, tended to mean separate, autonomous projects that live
under a project umbrella. I don't think anyone here is advocating
that, and I'd prefer we not have to explain what we mean over and
over to the rest of the Apache community....
I am advocating that we take stuff like the tx an j2ca implementation
and make it a "separate, autonomous projects that live under a
project umbrella". That way, those that are interested and
understand those technologies can choose how to develop the code.
They can choose when to branch, when to do releases, how to structure
their modules, and so on. There seems to be an interest in this from
the community.
-dain
