james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: Milestone from trunk
Date Sun, 04 May 2008 06:24:22 GMT
On Sat, May 3, 2008 at 12:38 PM, Noel J. Bergman <noel@devtech.com> 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

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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message