On Wed, Apr 16, 2008 at 8:23 PM, Danny Angus <[EMAIL PROTECTED]> wrote: > Glad you guys seem to have had some productive chat @apachecon. Sorry > I had to miss it this year, its the easter holidays and I went to > Aviemore with the family. Loads of snow on the ski slopes, which is > unusual for the time of year. > http://www.cairngormmountain.org.uk/web-cam
i was snowed on on the way to apachecon :-) > > >some looks ok, some looks questionable but i'm > > > not enough of an expert to judge. > > Oh I'm sure you're probably being modest. not really: the stuff that noel was worried about is something which requires in-depth knowledge of the specifications > I think that much of the > diff between 2.x branch and trunk suffers from not being tested > enough, and not having been subjected to the level of scrutiny which > it might have received in more active projects. > Which means my opinion is that the trunk isn't fit to release, but it > may contain code worth "working up" into production quality. 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 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. > > > 2. i want people to innovate on trunk rather than on their own > > > branches. > > This is a worthwhile goal, but has resulted in the lack of quality > assurance which blights the trunk. > We need to make a clear statement about the purpose and nature of the trunk. > We also need to work out how we avoid a situation where the delta > between branch and trunk continues to grow until they are too > different to manage. Perhaps we are already at that point. whether we've reached that point already or are just very close, i advocate abandoning the attempt to manage the delta: just accept that trunk is the classic unstable branch where committers are free to try things out there on a modular basis manage the progression of code from unstable (trunk) to stable (production) should be the management point 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. > > > IMHO modularisation is an inevitable consequence of > > > this approach. > > I've long said that modularisation is absolutely, fundamentally, > totally and utterly essential to the survival of the project. James > server is too complex to get your head round all of it in one go, > which dissuades people from casual participation, or put another way > James requires a significant commitment from contributors just to > understand what to change. The shame is that I believe that we loose > valuable contributions because of this overhead. +1 > > > noel prefers to see this process as allowing anyone to > > > dump junk in trunk and i have no probably about that language but > > > that's not the way i see things. > > Nor I, but Noel, as you say, is prone to talking in soundbites and > likes to make a drama out of a crisis. > I have no problem with people throwing stones into the pond to see > what floats to the surface, but I think the truth here is that we need > to establish an environment where there is a low cost for people to > innovate James, and the higher cost is associated with taking those > ideas into production. +1 > We lack any notion of degrees of quality assurance, and we lack a > lifecycle which allows changes to be promoted up the quality scale. > I think we need somewhere to dump junk, a way to pan the junk for > nuggets, and a clear path to "release" for chosen changes. +1 i advocate managing QA not in the transition from branches to trunk but from trunk to production - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
