-----BEGIN PGP SIGNED MESSAGE----- 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCmLSJaCoPKRow/gARAg35AJ9IfDwevATEMfyEuwv2JWMVoHygugCdFmLU qat86jpRD2Qu4ifDT4Upe48= =gXBM -----END PGP SIGNATURE-----
