On Sat, May 3, 2008 at 12:38 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Bernd Fondermann wrote: > > > Noel J. Bergman wrote: > >> That sort of thinking led Stefano to push to rush out v2.3.0 over my > >> objections that there was a critical memory leak. > > This is an obvious attempt to discredit other committers and bring back > > the old hostile atmosphere we were able to overcome lately. > > No, it is an attempt to discredit false lines of reasoning about code > quality. Software engineering theory aside, until we put the code into > real-world situations and not sanitized conditions, we have little basis for > claiming how it will work in the real-world. And we certainly don't have > any basis under software engineering for deriving a claim, since we have > never applied any to the code. And a mail server must be considered > reliable and solid in real-world use.
it's too easy to slip into antagonism: we need to step back and acknowledge that we are not the first project to find ourselves in this position i understand there are two strands of opinion about the relative code quality of trunk and this code base: please let's not get into this now. trunk is too big for all but the most dedicated to review in detail. so, this particular disagreement is one that cannot be resolved. let's avoid it for now. JAMES is mature. JAMES 2.3.x is a stable code base well tested live on the internet. for it's major use cases, i works well and any changes made (no matter how well tested and reviewed) risk shipping a version worse than it's predecessor. it is also progressively harder to add new features: all the necessary ones which can be safely and easily implemented have been added already. so each new release carries both higher risks and reduced gains. release paralysis is an inevitable consequence. JAMES fell into the trap: this technical issue became a social one and poisoned the atmosphere. i'd like to ask everyone to step back from the brink and leave the past behind. automated tests are necessary but not sufficient for mature products. they also need proving in real life. it is insufficient for developers alone to prove code bases: users also need to prove a release before the PMC can be confident that new stable releases are worthy. this means delivering artifacts for users to test. so, the techinical issue highlighted is a release process issue. JAMES needs to acknowledge and document that stable server versions will require an extended release process. other projects with stable code bases have adopted the following system with success. rather than requiring that an artifact is fully proved before the release is cut, they allow a proving process. they start by releasing milestones which target advanced users who really need to functionality and are willing to accept the risks. once the milestones seem to work well, they cut a numbered version: james-6.11.34, say. this version starts as a candidate. to be released, it must graduate by passing a set of quality elections: beta then alpha then fc. if it fails, then it's faults are addressed and then the process starts again with a new cut with a new number. by adopting this process for new releases of JAMES server, all released artifacts would be proved before their final release it is clear to me that requiring a priori that new server releases be fully proved before shipping any code to users will ensure that no more JAMES releases will be cut from any code base (stable or unstable). any PMC member not running x.y live on the internet would be duty bound to -1 any x.y release. i can happily live without any more JAMES server releases. the plan to release JAMES as a series of loosely coupled embeddable libraries works very well for me. but from a community perspective, being able to work together to create new JAMES server releases would be healthy. perhaps we should set history aside and just adopt a release process which other projects have found solves the proving issue. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
