On Tue, Apr 29, 2008 at 9:03 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: > > > Please try not to dredge in the distant past. The problem is that the > > passive majority have no ability to review the changes made. So there > > is no prospect of releasing trunk without Noel's active support. > > > > Sorry but telling me that JAMES doesn't release without Noel active support > simply let me stop even discussing how to release :-(
this is based on my assessment of the number of developers who would be willing to review in detail the changes between the last stable version and trunk. trunk is a big code base and - besides yourself - i think that noel is the only developer who might - if motivated - find the energy to review all the changes. > Historically most code in the JAMES codebase has been written by a single > developer and often NOT reviewed for real by anyone else. This also explain > how buggy the released code is/was. In fact I think that most code in trunk > (excluding IMAP that I don't know) has been reviewed much more (me, norman > and often bernd = 3 committers) than most code released in james 2.1. Maybe > the issues now is that who wrote that code is no more active, but keep > referring that trunk needs review is just a way to block releases. > > Noel and anyone else had 1.5 years to review the code and I guess not a > single line has been reviewed since that: sure Noel is telling that he will > vet trunk since that day but in fact he had no time to do this, yet. without noel, you would need to persuade other developers who are not familiar with trunk to +1 rather than +0. reducing the volume of code which must be reviewed would reduce the task involved in review and so increase the chances of independent review. releasing code as libraries rather than a monolithic application also reduces the effort required to review a release. > > Also, IIRC you also produced a list of new features in trunk. I wonder > > whether you could work out which could be delivered as library > > extensions. > > > > We already discussed this multiple times ;-) > > Only the smtp "fast fail" stuff could be isolated as a library, and in our > old proposal I and Norman told that we probably could have released v2.4 > using the v2.3 smtpserver and delaying the new smtpserver to a following > release, so I think it was not *the* problem. forget the past: the problems were just a symptom of problems within the community i would really like to be able to release a lightweight, embeddable SMTP protocol handling library. there is lots of interested in lightweight embeddable protocol handling libraries and since it's a library and not a server, then arguments about compliant default configurations would be irrelevant. lots of people are interested in fail-fast and releasing it in a library would help focus discussion in a positive way. in the medium term, i can see big advantages in eventually being able to maintain SMTP separately. the same engine could be used in different versions of JAMES. > Most of the code written in trunk has been written while v2.3 was prepared. > Most code that was simply backportable have been backported at that time. > Most changes that required API changes or changes in services/coupling > components structure was confined to trunk for the following major release. > Some of the code in trunk has been written 3 years ago... we should probably > rename "trunk" to "decanter" ;-) yeh: that was the problem. i think that we now need to decant the code from trunk into libraries so that it can be used in 2.x. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
