On Wed, Apr 16, 2008 at 9:50 PM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
> the major issue is that we don't collectively understand the quality > of the code in trunk nor how it differs from 2.4.x +1 I think, and hope, that that is what Noel, in his inimitable style, is pushing us towards doing. > > modularisation has some significant side benefits (which i'll outline > in another mail) but it also allows us to release code a chunk at a > time: we don't need to review all of trunk, just each bit in turn that > we want to release. +1 ... > manage the progression of code from unstable (trunk) to stable > (production) should be the management point +1 Agreed, if we look at sucessful projects with small numbers of commiters the role of the comitter is one of QA, patches are applied freely (CTR) but its the role of the committers to manage their progress thereafter as gatekeepers, not as coders or innovaters. > > for example, the loosely coupled mailets (whether cryto or standard) > should be extracted into separate products within a week or two. it > would not be unreasonable to diff the mailets with production and then > look to release these products soon. once we're happy with the > quality, we delete the duplicates from production and trunk and depend > on the library releases. +1 > i advocate managing QA not in the transition from branches to trunk > but from trunk to production +1 Exactly what I was trying to say :-) d. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
