geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian K. Wallace" <>
Subject Re: Geronimo subprojects?
Date Sat, 28 May 2005 18:12:25 GMT
Hash: SHA1

David Jencks wrote:
| So far I am completely unconvinced by any arguments in this thread.
| As a thought experiment, lets suppose we had already released a
| certified geronimo, say last month, and we had solved most of our build
| problems, say with maven2.  So, we have a certified branch and trunk,
| and all the geronimo developers are happily working on new features on
| trunk.
| In this scenario exactly what needs changing and why?
| thanks
| david jencks
I don't believe there's anything wrong with your 'thought experiment'.
My view is, however, that never is there work to be done everywhere in a
project. Taking your scenario above - all developers are happily working
on new features on trunk and there's a security problem in a particular
module. What went from "there's nothing wrong with this approach" now
shifts to "we need to get this fixed as soon as possible" for a
particular module. Again, this is most certainly doable with the
structure as-is. However, a faster fix/test/release cycle would be
possible if the module was able to handle it at that level instead of
involving the whole of geronimo's code and developer base for everything
from "if your code involves this module" (perhaps a 'new feature' not in
any way involved with what the bug is) to testing and documentation.

I don't think there is a "right" or "wrong" way to do it. Both work. I
personally believe smaller is better - then integrate. I also believe
this would promote multiple 'pre-built' deployment options (not "make it
possible", just promote). But I'm only one person. Just proposing
options for greater flexibility.
Version: GnuPG v1.2.5 (MingW32)


View raw message