[server] trunk -= IMAP/Mailbox source...?

[Robert Burrell Donkin <ro...@gmail.com>]

there's a lot of code in IMAP-Mailbox. this creates a large barrier to
entry both for developers wanting to work on IMAP-Maibox and for
developers who want to work on other components.

i'd like to think about moving the whole of the IMAP-mailbox code base
out of server/trunk and into server/protocols/imap/trunk (say). this
move would include the sieve mailet.

initially, trunk would then depend on SNAPSHOT jars committed into the
stage directory for IMAP support. in the medium term, i'd like to move
towards lightweight embeddable protocol libraries but i think it would
be better if that were discussed in a separate email.

opinions?

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk? (Was: [server] trunk -= IMAP/Mailbox source...?)

[Bernd Fondermann <be...@googlemail.com>]

On Tue, Apr 29, 2008 at 7:25 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>
> > 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.
> >
>
>  I'm not 100% sure but my understanding is that at least me, Norman and
> Bernd are +1 about releasing a milestone from trunk. I think what we miss is
> just a release manager, not the 3 +1 ;-)

indeed, I am +1.

  Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Milestone from trunk? (Was: [server] trunk -= IMAP/Mailbox source...?)

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> 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.

I'm not 100% sure but my understanding is that at least me, Norman and 
Bernd are +1 about releasing a milestone from trunk. I think what we 
miss is just a release manager, not the 3 +1 ;-)

> 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.

I will probably have updates in the next months on a related issue.

>>  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.

This is my point: *most* of that code require altered version of service 
interfaces or core api. If you extract libraries from trunk they won't 
work in 2.3.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] trunk -= IMAP/Mailbox source...?

[Robert Burrell Donkin <ro...@gmail.com>]

On Tue, Apr 29, 2008 at 9:03 AM, Stefano Bagnara <ap...@bago.org> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk

[Stefano Bagnara <ap...@bago.org>]

Bernd Fondermann ha scritto:
> On Sat, May 3, 2008 at 1:38 PM, Noel J. Bergman <no...@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.
> 
> Hardly. You could have chosen a different wording then, since there
> were a number of people who voted for this release. Instead you picked
> one. This is not technical. This is personal. And it weakens your
> technical reasoning.
> 
>   Bernd

The problem is not picking me in a group about something, IMHO. The 
problem is that Noel keeps repeating lies to discredit me and the code 
we wrote.

All of our interaction is in the mailing list. I'd like people to refer 
to something happened in the mailing list instead of reinventing the past.

Here is a detailed list of all the VOTEs about james 2.3.x releases on 
server-dev, who called them, when we did them:

Noel   - 2006/02/10 - [VOTE] James 2.3.0a1
Bago   - 2006/05/05 - [VOTE] James 2.3.0a2
Noel   - 2006/05/19 - [VOTE] 2.3.0a3 milestone
Noel   - 2006/06/02 - [VOTE] James 2.3.0 Beta 1
Bago   - 2006/07/06 - [VOTE] James 2.3.0b2 Release (Was: "votes" for 
next 2.3 release)
Norman - 2006/07/11 - [VOTE] James 2.3.0b3 Release
Norman - 2006/07/21 - [VOTE] James 2.3.0rc1 Release
Noel   - 2006/08/10 - [VOTE] JAMES v2.3 RC2 build posted
Noel   - 2006/09/01 - [VOTE] Release JAMES 2.3.0   >> FAILED
Noel   - 2006/09/12 - [VOTE] 2.3.0 RC3   >> FAILED
Norman - 2006/09/12 - [VOTE] 2.3.0 RC3 Again !
Norman - 2006/09/28 - [VOTE] 2.3.0 RC4   >> FAILED
Norman - 2006/09/29 - [VOTE] 2.3.0 RC4 again
Norman - 2006/10/08 - [VOTE] James 2.3.0rc5
Norman - 2006/10/19 - [VOTE] JAMES 2.3.0 final :-)
Norman - 2007/04/10 - [VOTE] JAMES 2.3.1RC1
Norman - 2007/04/25 - [VOTE] JAMES 2.3.1 (final)

Read this, and then read again Noel's message.. I forgot that Noel also 
tried to release James 2.3.0 final on 2006/09/01 (50 days before we 
finally released it). It is also really easy to open JIRA and to look 
who fixed what bugs and since what versions the bugs was open.

There is another *fact* about code quality: James 2.3.0 was the first 
release that let us to run James for more than one day without 
restarting it in cron. James 2.3.1 is the first release at all that 
allow us to run james forever without restarting it.
It seems that James PMC wasn't so warried about releasing unstable code 
when they released James 2.2.0 (FINAL) and previous with the knowledge 
that they needed a nightly restart, why are we discussing about the 
quality of a milestone without having a single proof that it doesn't work?

If needed I can provide links to message archives to prove each single 
sentence of this post.

I'd also like to thank Norman for the gigantic efforts in testing and 
preparing 2.3.x releases! It was fun to work on code and *real* bugs to 
increase the code quality. I remember we spent a lot of hours with 
James-dev code in production and debugging mine and his server to fix 
bugs. It was hard but cool. And I also thanks Noel for what he did until 
2 years ago. I prefer when he writes code.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk

[Bernd Fondermann <be...@googlemail.com>]

On Sat, May 3, 2008 at 1:38 PM, Noel J. Bergman <no...@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.

Hardly. You could have chosen a different wording then, since there
were a number of people who voted for this release. Instead you picked
one. This is not technical. This is personal. And it weakens your
technical reasoning.

  Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk

[Robert Burrell Donkin <ro...@gmail.com>]

On Mon, May 5, 2008 at 5:33 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>
> >
> > On Mon, May 5, 2008 at 4:00 PM, Stefano Bagnara <ap...@bago.org> wrote:
> >
> >
> > >  Can you say it again with different words? (concrete checklist/roadmap
> > > would be perfect to avoid my misunderstanding ;-) ).
> > >
> >
> > 1 Isn't it time we did a release?
> > 2 [PROPOSAL] Prepare release foo-x.y.z managed by Anne
> > 3 Focus on fixing code base
> > 4 Anne tags then prepares foo-x.y.z which is the release candidate and
> > makes it available for proving
> > 5 [VOTE] Promote foo-x.y.z to alpha
> > 6 [VOTE] Promote foo-x.y.z to beta
> > 7 [VOTE] Promote foo-x.y.z to fc
> >
> > if foo-x.y proves to be substandard then start again with foo-x.y.(z+1)
> >
>
>  So we simply do what we did for previous releases but each release will
> require multiple votes to define increasing quality levels, right? This way
> we don't require the quality to be FC at the first call.
>
>  Makes sense.
>
>  We did something similar with jSPF. it was 0.9.4 unstable, 0.9.5 unstable,
> 0.9.6 was stable so we had 0.9.6 declared as stable in the website.
>
>  So first we tag and release and then we decide what "quality label" to use
> to describe that release using a vote for each "quality step".
>
>  I will not be Anne (because Anne is a girl ;-) ), but I would be happy to
> test/fix during #3 and to write my votes in #1,#2,#5,#6 and #7.
>
>  IMHO #1 answer is an implicit YES for every source tree not having had a
> release in the last year.
>
>  The only thing I don't like of this approach is that if we tag before we
> decide the quality level we cannot include the quality label in the release
> file name (and artifacts deployed to the maven repository), but maybe this
> "missing information" worth the advantages of having a much easier entry
> level for releasing something.

just rename the artifact by hand

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On Mon, May 5, 2008 at 4:00 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>  Can you say it again with different words? (concrete checklist/roadmap
>> would be perfect to avoid my misunderstanding ;-) ).
> 
> 1 Isn't it time we did a release?
> 2 [PROPOSAL] Prepare release foo-x.y.z managed by Anne
> 3 Focus on fixing code base
> 4 Anne tags then prepares foo-x.y.z which is the release candidate and
> makes it available for proving
> 5 [VOTE] Promote foo-x.y.z to alpha
> 6 [VOTE] Promote foo-x.y.z to beta
> 7 [VOTE] Promote foo-x.y.z to fc
> 
> if foo-x.y proves to be substandard then start again with foo-x.y.(z+1)

So we simply do what we did for previous releases but each release will 
require multiple votes to define increasing quality levels, right? This 
way we don't require the quality to be FC at the first call.

Makes sense.

We did something similar with jSPF. it was 0.9.4 unstable, 0.9.5 
unstable, 0.9.6 was stable so we had 0.9.6 declared as stable in the 
website.

So first we tag and release and then we decide what "quality label" to 
use to describe that release using a vote for each "quality step".

I will not be Anne (because Anne is a girl ;-) ), but I would be happy 
to test/fix during #3 and to write my votes in #1,#2,#5,#6 and #7.

IMHO #1 answer is an implicit YES for every source tree not having had a 
release in the last year.

The only thing I don't like of this approach is that if we tag before we 
decide the quality level we cannot include the quality label in the 
release file name (and artifacts deployed to the maven repository), but 
maybe this "missing information" worth the advantages of having a much 
easier entry level for releasing something.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk

[Robert Burrell Donkin <ro...@gmail.com>]

On Mon, May 5, 2008 at 4:00 PM, Stefano Bagnara <ap...@bago.org> wrote:
>
> Robert Burrell Donkin ha scritto:
>
> > On Mon, May 5, 2008 at 10:07 AM, Stefano Bagnara <ap...@bago.org> wrote:
> >
> > > Robert Burrell Donkin ha scritto:
> > >
> > >
> > >
> > > > 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.
> > > >
> > > >
> > >  I guess we already know how to do this. As you can see in my other
> reply to
> > > this thread we made two 2.3.0 alpha releases from trunk in feb and may
> 2006.
> > > Then we branched for one more alpha, 3 betas and 4 release candidates
> during
> > > a 4 months period before a final release.
> > >
> >
> > the key difference is that the same release passes through a number of
> > different stages. a problem with the above is that encourages
> > development paralysis. either the code has to be forked or development
> > is frozen for long periods. both of which are harmful.
> >
>
>  Sorry, I probably misunderstood the sentence I quoted.
>  Can you say it again with different words? (concrete checklist/roadmap
> would be perfect to avoid my misunderstanding ;-) ).

1 Isn't it time we did a release?
2 [PROPOSAL] Prepare release foo-x.y.z managed by Anne
3 Focus on fixing code base
4 Anne tags then prepares foo-x.y.z which is the release candidate and
makes it available for proving
5 [VOTE] Promote foo-x.y.z to alpha
6 [VOTE] Promote foo-x.y.z to beta
7 [VOTE] Promote foo-x.y.z to fc

if foo-x.y proves to be substandard then start again with foo-x.y.(z+1)

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On Mon, May 5, 2008 at 10:07 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>
>>
>>> 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.
>>>
>>  I guess we already know how to do this. As you can see in my other reply to
>> this thread we made two 2.3.0 alpha releases from trunk in feb and may 2006.
>> Then we branched for one more alpha, 3 betas and 4 release candidates during
>> a 4 months period before a final release.
> 
> the key difference is that the same release passes through a number of
> different stages. a problem with the above is that encourages
> development paralysis. either the code has to be forked or development
> is frozen for long periods. both of which are harmful.

Sorry, I probably misunderstood the sentence I quoted.
Can you say it again with different words? (concrete checklist/roadmap 
would be perfect to avoid my misunderstanding ;-) ).

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk

[Robert Burrell Donkin <ro...@gmail.com>]

On Mon, May 5, 2008 at 10:07 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>
>
> > 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.
> >
>
>  I guess we already know how to do this. As you can see in my other reply to
> this thread we made two 2.3.0 alpha releases from trunk in feb and may 2006.
> Then we branched for one more alpha, 3 betas and 4 release candidates during
> a 4 months period before a final release.

the key difference is that the same release passes through a number of
different stages. a problem with the above is that encourages
development paralysis. either the code has to be forked or development
is frozen for long periods. both of which are harmful.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> 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.

I guess we already know how to do this. As you can see in my other reply 
to this thread we made two 2.3.0 alpha releases from trunk in feb and 
may 2006. Then we branched for one more alpha, 3 betas and 4 release 
candidates during a 4 months period before a final release.

Something similar happened for previous releases, too (it is easy to 
search archives for "[VOTE]" and the version number for curious).

The code size was very similar to what we have in trunk, the changes in 
sources in "diff" terms is a bit higher, but this is mainly due to some 
"automated refactoring" (extracting interfaces, moving code from a class 
to another, delegation patterns). In term of effective changes IMHO 
2.3.x contained much "critical" changes in core classes. In 2.3.x we had 
to fix MimeMessageWrapper issues and to make a lot of changes to that 
core class in order to remove most of our leaks. In trunk that core 
didn't change anymore.

I'll try to help with trunk in terms of bug fixing, but we don't have 
bugs in JIRA for trunk. Most of the open issues are there since years 
(and maybe should be marked as won't fix) or are new features we planned 
to add to trunk.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk

[Robert Burrell Donkin <ro...@gmail.com>]

On Sat, May 3, 2008 at 12:38 PM, Noel J. Bergman <no...@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
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

RE: Milestone from trunk

["Noel J. Bergman" <no...@devtech.com>]

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.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk

[Bernd Fondermann <bf...@brainlounge.de>]

Stefano Bagnara wrote:
> Noel J. Bergman ha scritto:
>> 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.

> 
> LOL
> very funny :-)

Keep laughing. It's not worth the fight.

   Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk

[Stefano Bagnara <ap...@bago.org>]

Noel J. Bergman ha scritto:
> That sort of thinking led Stefano to push to rush out v2.3.0 over my
> objections that there was a critical memory leak.

LOL
very funny :-)

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk

[Bernd Fondermann <be...@googlemail.com>]

On Mon, May 5, 2008 at 12:43 AM, Serge Knystautas <sk...@gmail.com> wrote:
> On Sun, May 4, 2008 at 8:47 AM, Bernd Fondermann
>  <be...@googlemail.com> wrote:
>  > On Sat, May 3, 2008 at 1:43 PM, Noel J. Bergman <no...@devtech.com> wrote:
>
> >  >  See above regarding Postage.  And keep in mind that I've used Postal and
>  >  >  Rabid for isolated testing in the past, but it (too) is not sufficient.  We
>  >  >  need the real world exposure.
>  >
>  >  Every test setup has its pros and cons. Unit test have a specific use,
>  >  so have isolated, reproducible functional or load tests.
>  >
>  >  Nancy (solaris zone, that is ;-)) has the disadvantage that it
>  >  probably will reveil some bugs/problems which are not (easily)
>  >  reproducible because we don't control the test data/load. This would
>  >  make some people with proper knowledge of testing not call it a
>  >  'test', more an  'experiment'. I think it's worthwhile anyway, but
>  >  you'd have to fall back to other tests after running into that certain
>  >  family of seldom problems.
>  >
>  >  I seem to have a hard time pitching Postage (which I actually wrote
>  >  after - or better because of - working with Postal and Rabid), which
>  >  allows to use specialized message factory objects. Write a custom
>  >  factory for every specific mail which leads to a specific false
>  >  behavior inside the Server. This makes Postage a fit for any kind a
>  >  functional test you might (have to) come up with.
>
>  IMO there's a trust that's needed that some random spam monkey can't
>  send a few wrong characters and cripple your mail server at 3am and
>  ruin your saturday night.  This arguably has to be created by
>  surviving in a cruel unsheltered world.

You are describing a localizable problem (dealing with bad character
input). Perfect for unit testing.
And yes, I agree, for detection, Nancy could be useful. Or a
randomized byte stream.

>  In terms of getting more useful data from that test install, I bet
>  someone who knows unix pretty well could write a way to log all
>  incoming port 25 traffic so we could get some real world attack
>  vectors/invalid mime messages/random junk.

That would be a lot of help. And a lot of data. And you still wouldn't
see problems produced by the timing of data sent (unless you record
and replay this, too).

  Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk

[Serge Knystautas <sk...@gmail.com>]

On Sun, May 4, 2008 at 8:47 AM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On Sat, May 3, 2008 at 1:43 PM, Noel J. Bergman <no...@devtech.com> wrote:
>  >  See above regarding Postage.  And keep in mind that I've used Postal and
>  >  Rabid for isolated testing in the past, but it (too) is not sufficient.  We
>  >  need the real world exposure.
>
>  Every test setup has its pros and cons. Unit test have a specific use,
>  so have isolated, reproducible functional or load tests.
>
>  Nancy (solaris zone, that is ;-)) has the disadvantage that it
>  probably will reveil some bugs/problems which are not (easily)
>  reproducible because we don't control the test data/load. This would
>  make some people with proper knowledge of testing not call it a
>  'test', more an  'experiment'. I think it's worthwhile anyway, but
>  you'd have to fall back to other tests after running into that certain
>  family of seldom problems.
>
>  I seem to have a hard time pitching Postage (which I actually wrote
>  after - or better because of - working with Postal and Rabid), which
>  allows to use specialized message factory objects. Write a custom
>  factory for every specific mail which leads to a specific false
>  behavior inside the Server. This makes Postage a fit for any kind a
>  functional test you might (have to) come up with.

IMO there's a trust that's needed that some random spam monkey can't
send a few wrong characters and cripple your mail server at 3am and
ruin your saturday night.  This arguably has to be created by
surviving in a cruel unsheltered world.

In terms of getting more useful data from that test install, I bet
someone who knows unix pretty well could write a way to log all
incoming port 25 traffic so we could get some real world attack
vectors/invalid mime messages/random junk.

-- 
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk

[Bernd Fondermann <be...@googlemail.com>]

On Sat, May 3, 2008 at 1:43 PM, Noel J. Bergman <no...@devtech.com> wrote:
> Bernd Fondermann wrote:
>  > Noel J. Bergman wrote:
>
> > > The proposal is based on the fact that every message delivered to the
>  zone
>  > > will be disposable spam.  Therefore, unlike performing some sort of faux
>  > > release without any basis, we will be testing in a risk-free
>  environment.
>  > > Every message can be dropped, the database can be corrupted, the server
>  can
>  > > leak memory and crash, and no one should care other than to fix it.
>
>  > Then you are talking about a closed environment test, so do I.
>
>  We're possibly differing on some English language semantics in terminology.
>  As long as we agree with the mechanics of the proposal, as above, I don't
>  care if you call it Nancy.  :-)
>
>
>  > > As an example of why this sort of testing is the right thing to do,
>  rather
>  > > than the idiocy of pushing out releases without real-world testing,
>  consider
>  > > our current situation with SVN.
>
>  > I never said we should release without testing beforehand.
>  > It is you who is ignoring the fact we have a safe black box
>  > testing tool right here in our project.
>
>  No, you appear to be ignoring that blackbox testing using Postage in
>  isolated networks is nowhere near sufficient to provide any basis for
>  assurance of real-world functionality.  I am addressing that lack.
>
>
>  > At the bottom line, I am happy that there seems to emerge some kind of
>  > common goal to start from TRUNK and put it into heavy testing, be it on
>  > a Solaris zone or locally using Postage.
>
>  See above regarding Postage.  And keep in mind that I've used Postal and
>  Rabid for isolated testing in the past, but it (too) is not sufficient.  We
>  need the real world exposure.

Every test setup has its pros and cons. Unit test have a specific use,
so have isolated, reproducible functional or load tests.

Nancy (solaris zone, that is ;-)) has the disadvantage that it
probably will reveil some bugs/problems which are not (easily)
reproducible because we don't control the test data/load. This would
make some people with proper knowledge of testing not call it a
'test', more an  'experiment'. I think it's worthwhile anyway, but
you'd have to fall back to other tests after running into that certain
family of seldom problems.

I seem to have a hard time pitching Postage (which I actually wrote
after - or better because of - working with Postal and Rabid), which
allows to use specialized message factory objects. Write a custom
factory for every specific mail which leads to a specific false
behavior inside the Server. This makes Postage a fit for any kind a
functional test you might (have to) come up with.

  Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

RE: Milestone from trunk

["Noel J. Bergman" <no...@devtech.com>]

Bernd Fondermann wrote:
> Noel J. Bergman wrote:
> > The proposal is based on the fact that every message delivered to the
zone
> > will be disposable spam.  Therefore, unlike performing some sort of faux
> > release without any basis, we will be testing in a risk-free
environment.
> > Every message can be dropped, the database can be corrupted, the server
can
> > leak memory and crash, and no one should care other than to fix it.

> Then you are talking about a closed environment test, so do I.

We're possibly differing on some English language semantics in terminology.
As long as we agree with the mechanics of the proposal, as above, I don't
care if you call it Nancy.  :-)

> > As an example of why this sort of testing is the right thing to do,
rather
> > than the idiocy of pushing out releases without real-world testing,
consider
> > our current situation with SVN.

> I never said we should release without testing beforehand.
> It is you who is ignoring the fact we have a safe black box
> testing tool right here in our project.

No, you appear to be ignoring that blackbox testing using Postage in
isolated networks is nowhere near sufficient to provide any basis for
assurance of real-world functionality.  I am addressing that lack.

> At the bottom line, I am happy that there seems to emerge some kind of
> common goal to start from TRUNK and put it into heavy testing, be it on
> a Solaris zone or locally using Postage.

See above regarding Postage.  And keep in mind that I've used Postal and
Rabid for isolated testing in the past, but it (too) is not sufficient.  We
need the real world exposure.

> +1, count me in.

:-)  There we go.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk

[Bernd Fondermann <bf...@brainlounge.de>]

Noel J. Bergman wrote:
> Bernd Fondermann wrote:
> 
>> I don't trust 2.3.1 more than TRUNK or any other James snapshot.
> 
> That's really too bad, since we know from empirical experience that JAMES
> 2.3 + my patches hold up to years of real-world production loads.  We have
> some justification that 2.3.x are OK because we're not getting reports of
> failures from end users.  We have not an iota of demonstrable quality in
> trunk save for your unit tests, which while gratefully acknowledged and
> highly valued are *NOT* a sufficient indicator of real-world functionality,
> nor do they in any way speak to performance or design issues.

I agree. (Except that Stefano must be credited for most of the unit 
tests, actually, not me.)
I know what unit test are good for and what functional tests are good for.

>> And we all know that TRUNK is not tested in the small. So proposing to
>> expose it in the large while at the same time repeating the mantra of
>> "TRUNK implements Disposable" just doesn't make sense to me.
> 
> Well, then let me make this clear.
> 
> The proposal is based on the fact that every message delivered to the zone
> will be disposable spam.  Therefore, unlike performing some sort of faux
> release without any basis, we will be testing in a risk-free environment.
> Every message can be dropped, the database can be corrupted, the server can
> leak memory and crash, and no one should care other than to fix it.

Then you are talking about a closed environment test, so do I.

> As an example of why this sort of testing is the right thing to do, rather
> than the idiocy of pushing out releases without real-world testing, consider
> our current situation with SVN. 

I never said we should release without testing beforehand.
It is you who is ignoring the fact we have a safe black box testing tool 
right here in our project.

At the bottom line, I am happy that there seems to emerge some kind of 
common goal to start from TRUNK and put it into heavy testing, be it on 
a Solaris zone or locally using Postage. This is actually what I am 
proposing for weeks and months now.

+1, count me in.

   Bernd





---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

RE: Milestone from trunk

["Noel J. Bergman" <no...@devtech.com>]

Bernd Fondermann wrote:

> I don't trust 2.3.1 more than TRUNK or any other James snapshot.

That's really too bad, since we know from empirical experience that JAMES
2.3 + my patches hold up to years of real-world production loads.  We have
some justification that 2.3.x are OK because we're not getting reports of
failures from end users.  We have not an iota of demonstrable quality in
trunk save for your unit tests, which while gratefully acknowledged and
highly valued are *NOT* a sufficient indicator of real-world functionality,
nor do they in any way speak to performance or design issues.

> And we all know that TRUNK is not tested in the small. So proposing to
> expose it in the large while at the same time repeating the mantra of
> "TRUNK implements Disposable" just doesn't make sense to me.

Well, then let me make this clear.

The proposal is based on the fact that every message delivered to the zone
will be disposable spam.  Therefore, unlike performing some sort of faux
release without any basis, we will be testing in a risk-free environment.
Every message can be dropped, the database can be corrupted, the server can
leak memory and crash, and no one should care other than to fix it.

As an example of why this sort of testing is the right thing to do, rather
than the idiocy of pushing out releases without real-world testing, consider
our current situation with SVN.  Because of an emergency, an untested
configuration of a new (for this purposs) but supposedly stable operating
system and new hardware was precipituously put into place without any proper
testing.  So we have had crash after crash for a week, despite the best
interests of an entire team of very talented people spending tremendous
hours on the singular task of keeping an SVN server running.

In the past, I have been the primary real-world tester before a release ever
happened.  I do not trust trunk to be other than disposable.  The above
environment would provide us with a means for doing real-world testing, and
establish a level of trust in the code necessary to even contemplate putting
it into a critical position (pending fixes, etc.).

> I wouldn't like to see James loosing its credibility and trust caused
> by a bug or untested feature causing it to sent out email to
> everywhere from an apache.org zone.

Which part of:

> > We will need to be careful to initially DISABLE the ability to send
mail,
> > and open it up very carefully to MAKE SURE THAT WE DON'T accidentally
> > create a relay of any kind.

was not clear to you?

> We already have tools for load- and integrity-testing a mail server
> locally and without exposing it to the outside world right here at our
> fingertips.

That sort of thinking led Stefano to push to rush out v2.3.0 over my
objections that there was a critical memory leak.

> Actually, I think a release labelled as "milestone" and thus clearly
> attributed as "not-production-ready-yet" is more clever than actually
> exposing it in a production-like environment on a solaris zone
> untested.

Wrong.  Fundamentally, categorically, wrong.  We do NOT put our stamp of
approval, even one so "weak" as "milestone" on untested code and screw over
our users, who trust us, because some folks here don't understand the
fundamentals of stability and reliability.  JAMES is not a game or hobby.
E-mail service is business-critical and time-critical.  It tolerates near
zero defects.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk

[Bernd Fondermann <be...@googlemail.com>]

On Fri, May 2, 2008 at 9:29 PM, Noel J. Bergman <no...@devtech.com> wrote:
> Robert Burrell Donkin wrote:
>
>  > there is no prospect of releasing trunk without Noel's active support.
>
>  I hope that's not actually the case, but regardless, what does the PMC think
>  of the following?
>
>  Trunk is simply not trustworthy.  Anyone who would consider releasing from
>  trunk would do little to improve my opinion of said person's competence to
>  make that judgement.  Frankly, I consider a "milestone" from trunk to be
>  less than a bad joke, and would vote -1 on the grounds that no one can
>  consider trunk even close to being supportable.  You and Danny have recently
>  said almost the same thing about trunk being unsupportable.  So what is the
>  point of a milestone?  We already do nightly builds.  Anyone who wants to
>  jump off a mountain in the dark without a parachute and pray for the best is
>  invited to try the nightly builds.
>
>  That said, there are several things that we could do it improve trust in the
>  code.  One is the plan that we had discussed at ApacheCon: start from known
>  good code -- the JAMES 2.3.x codebase -- and incrementally merge parts of
>  trunk into it as they are reviewed.  I consider that to be a good and viable
>  option, and would have started on that already were it not for my own
>  server's failure last week, and the SVN issues this week.
>
>  Second is to get people to review trunk en masse.  I don't consider that
>  likely, but if everyone wants to give it a shot, I'm willing to be
>  surprised.
>
>  However, simply reviewing the code won't come even remotely close to cutting
>  it.  One reason why the trusted code is trusted isn't just that it has been
>  reviewed, but that it has been EXTENSIVELY tested in production over a long
>  span of time.
>
>  So regardless of which approach we take, and certainly crucial to any
>  attempt to evaluate the code quality of trunk, we need to hammer at the
>  build.  And not just within a sanitized cleanroom network, which is what
>  prevented Stefano from seeing the problems staring those of us who actually
>  use JAMES in the face.
>
>  So what I propose is that we setup a JAMES zone, and start to deploy JAMES
>  in that zone.  That will be published in the DNS, and quite shortly we
>  should start to see a lot of connections coming to it as millions of
>  spambots start to exercise JAMES for us.  So we'll have a built-in load test
>  running, courtesy of the botnets, and we can just watch the build work or
>  crash in flames without any concern for lost messages.  We will need to be
>  careful to initially disable the ability to send mail, and open it up very
>  carefully to make sure that we don't accidentally create a relay of any
>  kind.  We could, for example, setup an SMTPS handler, and allow PMC members
>  to send via it, or alternatively, allow relaying only when the connection
>  comes from p.a.o.
>
>  This would be a really good thing for helping us to improve trust in the
>  code, both now and as it evolves.

I don't trust 2.3.1 more than TRUNK or any other James snapshot.
And we all know that TRUNK is not tested in the small. So proposing to
expose it in the large while at the same time repeating the mantra of
"TRUNK implements Disposable" just doesn't make sense to me. Noel, you
are inconsistent ;-)

I wouldn't like to see James loosing its credibility and trust caused
by a bug or untested feature causing it to sent out email to
everywhere from an apache.org zone.

We already have tools for load- and integrity-testing a mail server
locally and without exposing it to the outside world right here at our
fingertips.

If we are positive with local tests we can deploy to a zone. But
without testing locally before, I think this is unprofessional.
Actually, I think a release labelled as "milestone" and thus clearly
attributed as "not-production-ready-yet" is more clever than actually
exposing it in a production-like environment on a solaris zone
untested.

Additionally - Noel, if you are aware of any specific, reproducible
problems with TRUNK, please take the time and document these on the
mailing list or in JIRA.

In short: +1 to deploy to a zone _after_ testing it sufficiently locally.

  Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk

[Stefano Bagnara <ap...@bago.org>]

Bernd Fondermann ha scritto:
> On Mon, May 5, 2008 at 11:20 AM, Stefano Bagnara <ap...@bago.org> wrote:
>>  What domain can we host for the tests?
> 
> I would like to donate a domain, for example james-testing.org. I
> would be able to admin the nameserver according to our needs.

Good. The more domains the more spam ;-)
I could provide some second level domains (james-testing.bago.org / 
james-testing.void.it ).

>>  If we don't make this test installation the default MX for some domain and
>> we don't use some email address in public messages I don't expect botnets to
>> hit us so fast. Any ideas?
> 
> put some mail addresses on a wiki page?
> 
>   Bernd

This would be a good start, but it took a lot of time before I saw 
botnets attacking my servers, maybe today is faster.

BTW even if we don't get a million connection per day like me and Noel 
are experiencing on production servers it will be interesting anyway 
even for collaborative debugging a as a sandbox to collaboratively 
reproduce issues.

Are we going to test file/db or dbfile repositories?
Do we plan to use the standard configuration or an "as complex as 
possible" configuration?

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk

[Bernd Fondermann <be...@googlemail.com>]

On Mon, May 5, 2008 at 11:20 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann ha scritto:
>
>
> > Serge Knystautas wrote:
> >
> > > On Fri, May 2, 2008 at 3:29 PM, Noel J. Bergman <no...@devtech.com>
> wrote:
> > >
> > > >  So what I propose is that we setup a JAMES zone, and start to deploy
> JAMES
> > > >  in that zone.  That will be published in the DNS, and quite shortly
> we
> > > >  should start to see a lot of connections coming to it as millions of
> > > >  spambots start to exercise JAMES for us.  So we'll have a built-in
> load test
> > > >  running, courtesy of the botnets, and we can just watch the build
> work or
> > > >  crash in flames without any concern for lost messages.  We will need
> to be
> > > >  careful to initially disable the ability to send mail, and open it up
> very
> > > >  carefully to make sure that we don't accidentally create a relay of
> any
> > > >  kind.  We could, for example, setup an SMTPS handler, and allow PMC
> members
> > > >  to send via it, or alternatively, allow relaying only when the
> connection
> > > >  comes from p.a.o.
> > > >
> > >
> > > I see no reason to object to this proposal.  If this helps give Noel
> > > extra confidence in the codebase and it does not create extra burden
> > > on other committers, why say anything but "sounds great"?
> > >
> >
> > "extra confidence" :-)
> >
> > Sounds great, but going into testing with TRUNK essentially was proposed
> for month. Now someone who torpedoed this approach and repeatedly said:
> "Don't even look at this code" reiterates this. That really makes me happy,
> but it sounded great to me months ago already.
> >
> > Now let's get this zone up and running.
> > Maybe Norman can fill us in about when new zones will be available. IIRC,
> at ApacheCon he said that the machine hosting the zones needs upgrades
> before new zones can be added.
> >
> >  Bernd
> >
>
>  +1
>
>  What domain can we host for the tests?

I would like to donate a domain, for example james-testing.org. I
would be able to admin the nameserver according to our needs.

>  If we don't make this test installation the default MX for some domain and
> we don't use some email address in public messages I don't expect botnets to
> hit us so fast. Any ideas?

put some mail addresses on a wiki page?

  Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk

[Stefano Bagnara <ap...@bago.org>]

Bernd Fondermann ha scritto:
> Serge Knystautas wrote:
>> On Fri, May 2, 2008 at 3:29 PM, Noel J. Bergman <no...@devtech.com> wrote:
>>>  So what I propose is that we setup a JAMES zone, and start to deploy 
>>> JAMES
>>>  in that zone.  That will be published in the DNS, and quite shortly we
>>>  should start to see a lot of connections coming to it as millions of
>>>  spambots start to exercise JAMES for us.  So we'll have a built-in 
>>> load test
>>>  running, courtesy of the botnets, and we can just watch the build 
>>> work or
>>>  crash in flames without any concern for lost messages.  We will need 
>>> to be
>>>  careful to initially disable the ability to send mail, and open it 
>>> up very
>>>  carefully to make sure that we don't accidentally create a relay of any
>>>  kind.  We could, for example, setup an SMTPS handler, and allow PMC 
>>> members
>>>  to send via it, or alternatively, allow relaying only when the 
>>> connection
>>>  comes from p.a.o.
>>
>> I see no reason to object to this proposal.  If this helps give Noel
>> extra confidence in the codebase and it does not create extra burden
>> on other committers, why say anything but "sounds great"?
> 
> "extra confidence" :-)
> 
> Sounds great, but going into testing with TRUNK essentially was proposed 
> for month. Now someone who torpedoed this approach and repeatedly said: 
> "Don't even look at this code" reiterates this. That really makes me 
> happy, but it sounded great to me months ago already.
> 
> Now let's get this zone up and running.
> Maybe Norman can fill us in about when new zones will be available. 
> IIRC, at ApacheCon he said that the machine hosting the zones needs 
> upgrades before new zones can be added.
> 
>   Bernd

+1

What domain can we host for the tests?
If we don't make this test installation the default MX for some domain 
and we don't use some email address in public messages I don't expect 
botnets to hit us so fast. Any ideas?

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk

[Bernd Fondermann <bf...@brainlounge.de>]

Serge Knystautas wrote:
> On Fri, May 2, 2008 at 3:29 PM, Noel J. Bergman <no...@devtech.com> wrote:
>>  So what I propose is that we setup a JAMES zone, and start to deploy JAMES
>>  in that zone.  That will be published in the DNS, and quite shortly we
>>  should start to see a lot of connections coming to it as millions of
>>  spambots start to exercise JAMES for us.  So we'll have a built-in load test
>>  running, courtesy of the botnets, and we can just watch the build work or
>>  crash in flames without any concern for lost messages.  We will need to be
>>  careful to initially disable the ability to send mail, and open it up very
>>  carefully to make sure that we don't accidentally create a relay of any
>>  kind.  We could, for example, setup an SMTPS handler, and allow PMC members
>>  to send via it, or alternatively, allow relaying only when the connection
>>  comes from p.a.o.
> 
> I see no reason to object to this proposal.  If this helps give Noel
> extra confidence in the codebase and it does not create extra burden
> on other committers, why say anything but "sounds great"?

"extra confidence" :-)

Sounds great, but going into testing with TRUNK essentially was proposed 
for month. Now someone who torpedoed this approach and repeatedly said: 
"Don't even look at this code" reiterates this. That really makes me 
happy, but it sounded great to me months ago already.

Now let's get this zone up and running.
Maybe Norman can fill us in about when new zones will be available. 
IIRC, at ApacheCon he said that the machine hosting the zones needs 
upgrades before new zones can be added.

   Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Milestone from trunk

[Serge Knystautas <sk...@gmail.com>]

On Fri, May 2, 2008 at 3:29 PM, Noel J. Bergman <no...@devtech.com> wrote:
>  So what I propose is that we setup a JAMES zone, and start to deploy JAMES
>  in that zone.  That will be published in the DNS, and quite shortly we
>  should start to see a lot of connections coming to it as millions of
>  spambots start to exercise JAMES for us.  So we'll have a built-in load test
>  running, courtesy of the botnets, and we can just watch the build work or
>  crash in flames without any concern for lost messages.  We will need to be
>  careful to initially disable the ability to send mail, and open it up very
>  carefully to make sure that we don't accidentally create a relay of any
>  kind.  We could, for example, setup an SMTPS handler, and allow PMC members
>  to send via it, or alternatively, allow relaying only when the connection
>  comes from p.a.o.

I see no reason to object to this proposal.  If this helps give Noel
extra confidence in the codebase and it does not create extra burden
on other committers, why say anything but "sounds great"?

Noel, is this something that you can setup with the nightly builds and
a tweaked configuration, or do you need more community support to get
this rolling?  If it's the former, then giddyup!

-- 
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] trunk -= IMAP/Mailbox source...?

[Stefano Bagnara <ap...@bago.org>]

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 :-(

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.

> 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.
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" ;-)

The problem is that I cannot help with the review issue: I already 
reviewed that code and people seems not to trust this (or maybe it is 
not enough). Now you tell me that our PMC only trusts Noel reviews. This 
make sense and explain many things, but this also make it clear that I 
cannot help furthermore in this task. Let's simply wait Noel.

I am OT and I hope someone else will still find the topic and tell us if 
they think moving IMAP somewhere else is a good step.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

re: Milestone from trunk

["Noel J. Bergman" <no...@devtech.com>]

Robert Burrell Donkin wrote:

> there is no prospect of releasing trunk without Noel's active support.

I hope that's not actually the case, but regardless, what does the PMC think
of the following?

Trunk is simply not trustworthy.  Anyone who would consider releasing from
trunk would do little to improve my opinion of said person's competence to
make that judgement.  Frankly, I consider a "milestone" from trunk to be
less than a bad joke, and would vote -1 on the grounds that no one can
consider trunk even close to being supportable.  You and Danny have recently
said almost the same thing about trunk being unsupportable.  So what is the
point of a milestone?  We already do nightly builds.  Anyone who wants to
jump off a mountain in the dark without a parachute and pray for the best is
invited to try the nightly builds.

That said, there are several things that we could do it improve trust in the
code.  One is the plan that we had discussed at ApacheCon: start from known
good code -- the JAMES 2.3.x codebase -- and incrementally merge parts of
trunk into it as they are reviewed.  I consider that to be a good and viable
option, and would have started on that already were it not for my own
server's failure last week, and the SVN issues this week.

Second is to get people to review trunk en masse.  I don't consider that
likely, but if everyone wants to give it a shot, I'm willing to be
surprised.

However, simply reviewing the code won't come even remotely close to cutting
it.  One reason why the trusted code is trusted isn't just that it has been
reviewed, but that it has been EXTENSIVELY tested in production over a long
span of time.

So regardless of which approach we take, and certainly crucial to any
attempt to evaluate the code quality of trunk, we need to hammer at the
build.  And not just within a sanitized cleanroom network, which is what
prevented Stefano from seeing the problems staring those of us who actually
use JAMES in the face.

So what I propose is that we setup a JAMES zone, and start to deploy JAMES
in that zone.  That will be published in the DNS, and quite shortly we
should start to see a lot of connections coming to it as millions of
spambots start to exercise JAMES for us.  So we'll have a built-in load test
running, courtesy of the botnets, and we can just watch the build work or
crash in flames without any concern for lost messages.  We will need to be
careful to initially disable the ability to send mail, and open it up very
carefully to make sure that we don't accidentally create a relay of any
kind.  We could, for example, setup an SMTPS handler, and allow PMC members
to send via it, or alternatively, allow relaying only when the connection
comes from p.a.o.

This would be a really good thing for helping us to improve trust in the
code, both now and as it evolves.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] trunk -= IMAP/Mailbox source...?

[Robert Burrell Donkin <ro...@gmail.com>]

On 4/28/08, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On Mon, Apr 28, 2008 at 7:21 PM, Stefano Bagnara <ap...@bago.org> wrote:
> >> Robert Burrell Donkin ha scritto:
> >>> who's interested in releasing IMAP? not me, for one. i can live very
> >>> happily enough without any releases for the forseeable future.
> >>> releases attract users, not developers.
> >>>
> >>  True. Just take into consideration that many JAMES developers knew JAMES
> as
> >> users and then decided to start hacking the code.
> >>  1) Releases attract users that could be future developers
> >>  2) Releases give some developers motivations/satisfaction to keep
> working.
> >
> > i don't have the energy to cope with users. even developers are
> > difficult since the codebase is in flux...
>
> Even if I lost my motivation in coping with the PMC I think I'm still
> doing user support as much as possible. Yes, I reduced my activity there
> too, but I try to keep running with users as I think they are the only
> key for JAMES issues: we need new users, new developers, a new community
> driven by new smart people. Since I joined james (2005) I replied almost
> an average of 1 message per day on james-user. This does not catch up
> with user questions, but this is A LOT. Norman also helped in the last
> years. Danny, Serge and expecially Noel worked very hard on the
> james-user list in the previous years. Unfortunately I guess both the
> users community and the developers community has been reduced since
> 2002-2003 by a 5 factor.

I was just talking about my motivation. I understand other developers
feel differently. I am interested in helping the JAMES community heal
itself but do not share all the same goals.

>
> >>  I, for one, started as an user of the 2.1 and then 2.2 and then I've had
> to
> >> fix/change a lot of code and decided to try to be a developer, I'm very
> >> happy for 2.3.0, and then I stopped because I had no enough
> >> energy/motivation to make another release like that one and I see no way
> to
> >> release again. But this is me. And this is past.
> >
> > i don't have the energy to do everything. i can see a route towards
> > new JAMES releases involving considerable code from trunk if not trunk
> > itself. i just can't see any chance of releasing trunk at all. but if
> > no one else who wants releases has energy to contribute then i'm not
> > going waste my time.
>
> I would +1 any attempt to branch or release milestones from trunk even
> tomorrow. I would test the resulting milestone, I would report bugs, I
> would *probably* report patches, too. But I won't push this, as I've
> been accused to push things and I'll wait for others to push now :-)
> I hope you get me as an "opinionist" and not as a contender: I really
> admire your work and your motivation (I've been there) and I hope you
> understand that in practice I will rarely use my -1, but I now like to
> scream as loud as I can because most of our PMC tends to sleep, and I
> want them to hear and take reasoned decisions ;-)

Inappropriate inaction is as bad as inappropriate action
>
> >>> IMAP is orthogonal to the community issues surrounding trunk. IMAP is
> >>> not tightly coupled to the rest of JAMES. if the community issues
> >>> remain unresolved when IMAP is ready for release, the easiest approach
> >>> would be to backport to a uncontroversial version.
> >>>
> >>> the only way that trunk is going to get released is if someone steps
> >> forward
> >>  I agree. What I didn't agree is that removing IMAP is a step forward and
> >> that this is a community opinion.
> >
> > i never said removing IMAP is the majority opinion: it's bound to be
> unpopular
>
> You are right, I made a conclusion based on a couple of sentences and
> maybe I was wrong.
> I told:
> "IMHO there is no shame in releasing code marked as unstable together
> with stable code. We introduced modules also for this, didn't we?" and
> you replied:
> "yes but IMHO that's not an opinion shared by the majority of those
> with binding VOTEs."
>
> If I understood this was what made you decide to start removing IMAP,
> but maybe I misunderstood.
> I just want to tell you "please check that someone else in the PMC, in
> addition to Noel, thinks that releasing unstable modules from trunk is a
> shame", because I only count him from my mailing list archive lookups,
> and I really hope we don't still count Noel as the majority ;-)
>
> I could accept to give *yours* idea (as active developers against
> speak-only people, including me) the power of majority, but not Noel's ;-)
>

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.

> >> But I already said that I trust you on
> >> this. I will not -1 this.
> >>  If this is needed then let's make another "top level" project,
> >> svn/james/imapserver (with no weird trees, please ;-) ), or let's push
> back
> >> to sandbox (I would hate this, but if THE COMMUNITY think it is better, I
> >> will not vote down this too).
> >
> > JAMES suffers from everyone doing anything interesting in the sandbox.
> > this is bad. the reasoning behind the modular build is that anyone
> > should be able to try new stuff without having to fork JAMES. that's
> > now easy in trunk.
>
> ATM JAMES suffers from everyone doing nothing :-(
> The sandbox ERA is already past.. it lasted few months...
> As I said I would hate moving IMAP to sandbox. It was simply a statement
> to tell you what I would "accept" without a -1. If I understood it
> correctly you was fine with keeping IMAP in trunk or moving it to
> svn/james/imapserver, am I wrong? (I just didn't like the
> svn/james/server/imapserver solution, but I hope this is a minor
> technical detail)
Just a detail

>
> >>> i think that the lack of releases is unhealthy for the community. i
> >>> also understand that many developers feel frustrated. i see no reasons
> >>> why JAMES couldn't release a couple of components a month for the next
> >>> year or so provided that the people who want more releases step
> >>> forward.
> >>>
> >>  I think you understand that when this community try for real and
> concretely
> >> to release something I always try to help someway (site stuff, release
> >> tests, maven issues). Just don't ask me to push things. I gave up with
> >> pushing :-) . I will join when I see something I consider concrete and
> >> realistic.
> >
> > if no one's willing to push forward releases then they aren't going to
> > happen. previously, you were pushing against too many in the community
> > to have a realistic chance of success. the art is to approach from a
> > different perspective.
>
> Have you understood WHO was against and WHY? I'm still waiting to
> understand why and to get counterproposal or to get some "sorry, I was
> wrong, please try again now". Sometimes it is good to read again that
> old messages. Read the motivations.. people was scared because they need
> some more months to complete their work... I guess they had their months
> now, maybe now everything is ok to release ;-)
> I still hope you will try to push, because if you don't do this, no one
> else will do now. I don't expect anymore the community that complained
> me and Norman at the end of 2006 to get a better solution to our
> proposal (I checked my spam folder and
is not there ;-) ).

It's not my fight. I have too much code I need to write both in JAMES
and elsewhere.

>
> > i think releasing mailet-api, mailet-base, std-mailet and crypto-mail
> > in the next month is not unrealistic if someone else were to step
> > forward to act as release manager so we can spread the load. we will
> > then have started to release the 3.0 code base in a way that allow
> > it's encorporation within the 2.x codebase.
>
> I will not do the release manager, but I can try helping with mailets
> and coping with dependencies and code analysis as I did in the original
> message identifying what mailets/matchers can be moved or not and why.
That is useful. How about coming up with some solutions for the rest?

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.
> > there is a lot of interest in lightweight, embeddable protocol
> > handling libraries. one way to reassemble JAMES would be to extract
> > our popular protocol into separate products. we then build the
> > headline JAMES server from loosely coupled components with separate
> > versioning. the more i look at the codebase, the more i think that if
> > only avalon were not so intrusive this would be a realistic
> > possibility. this would allow SMTP to be released when it were ready
> > and arguments about that protocol to be restricted just to that
> > codebase. it would also allow JAMES components to be easily reused in
> > other projects (there are several who would be interested if only
> > JAMES were not so monolithic).
> >
> > - robert
>
> I don't consider JAMES a so big monolithic application. IMHO JAMES has a
> small-medium codebase. I'm used to work on much larger source trees and
> I don't feel this need to break things apart (but I guess you already
> got t

JAMES is too monolithic to work well as an open source project with
only volunteer developers. Commercial trees are much bigger but they
are organized differently. Big, monolithic codebases prevents code
sharing and is a major barrier to new developers who are interested
only in a limited feature set.

Open source projects work best when they are bushy: a small kernel
plus modules.

> That said I'm working on avalon free, seda based, protocols libraries
> outside ASF/JAMES so I really agree on the rest of your sentence.
>
> The more we talk, the more I think you're simply late (wrt JAMES
> involvement) and that if you was here 2 years ago we would have james
> *4.0* out now!

Not sure. Increasingly I think most of the improvements made in trunk
could be added as pluggable extensions to the 2.x codebase.
>
> Stefano
>
> PS: OK, I realize I should not consume so much of your time. My "bar
> discussions" are not concrete steps to release.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] trunk -= IMAP/Mailbox source...?

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On Mon, Apr 28, 2008 at 7:21 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> who's interested in releasing IMAP? not me, for one. i can live very
>>> happily enough without any releases for the forseeable future.
>>> releases attract users, not developers.
>>>
>>  True. Just take into consideration that many JAMES developers knew JAMES as
>> users and then decided to start hacking the code.
>>  1) Releases attract users that could be future developers
>>  2) Releases give some developers motivations/satisfaction to keep working.
> 
> i don't have the energy to cope with users. even developers are
> difficult since the codebase is in flux...

Even if I lost my motivation in coping with the PMC I think I'm still 
doing user support as much as possible. Yes, I reduced my activity there 
too, but I try to keep running with users as I think they are the only 
key for JAMES issues: we need new users, new developers, a new community 
driven by new smart people. Since I joined james (2005) I replied almost 
an average of 1 message per day on james-user. This does not catch up 
with user questions, but this is A LOT. Norman also helped in the last 
years. Danny, Serge and expecially Noel worked very hard on the 
james-user list in the previous years. Unfortunately I guess both the 
users community and the developers community has been reduced since 
2002-2003 by a 5 factor.

>>  I, for one, started as an user of the 2.1 and then 2.2 and then I've had to
>> fix/change a lot of code and decided to try to be a developer, I'm very
>> happy for 2.3.0, and then I stopped because I had no enough
>> energy/motivation to make another release like that one and I see no way to
>> release again. But this is me. And this is past.
> 
> i don't have the energy to do everything. i can see a route towards
> new JAMES releases involving considerable code from trunk if not trunk
> itself. i just can't see any chance of releasing trunk at all. but if
> no one else who wants releases has energy to contribute then i'm not
> going waste my time.

I would +1 any attempt to branch or release milestones from trunk even 
tomorrow. I would test the resulting milestone, I would report bugs, I 
would *probably* report patches, too. But I won't push this, as I've 
been accused to push things and I'll wait for others to push now :-)
I hope you get me as an "opinionist" and not as a contender: I really 
admire your work and your motivation (I've been there) and I hope you 
understand that in practice I will rarely use my -1, but I now like to 
scream as loud as I can because most of our PMC tends to sleep, and I 
want them to hear and take reasoned decisions ;-)

>>> IMAP is orthogonal to the community issues surrounding trunk. IMAP is
>>> not tightly coupled to the rest of JAMES. if the community issues
>>> remain unresolved when IMAP is ready for release, the easiest approach
>>> would be to backport to a uncontroversial version.
>>>
>>> the only way that trunk is going to get released is if someone steps
>> forward
>>  I agree. What I didn't agree is that removing IMAP is a step forward and
>> that this is a community opinion.
> 
> i never said removing IMAP is the majority opinion: it's bound to be unpopular

You are right, I made a conclusion based on a couple of sentences and 
maybe I was wrong.
I told:
"IMHO there is no shame in releasing code marked as unstable together 
with stable code. We introduced modules also for this, didn't we?" and 
you replied:
"yes but IMHO that's not an opinion shared by the majority of those
with binding VOTEs."

If I understood this was what made you decide to start removing IMAP, 
but maybe I misunderstood.
I just want to tell you "please check that someone else in the PMC, in 
addition to Noel, thinks that releasing unstable modules from trunk is a 
shame", because I only count him from my mailing list archive lookups, 
and I really hope we don't still count Noel as the majority ;-)

I could accept to give *yours* idea (as active developers against 
speak-only people, including me) the power of majority, but not Noel's ;-)

>> But I already said that I trust you on
>> this. I will not -1 this.
>>  If this is needed then let's make another "top level" project,
>> svn/james/imapserver (with no weird trees, please ;-) ), or let's push back
>> to sandbox (I would hate this, but if THE COMMUNITY think it is better, I
>> will not vote down this too).
> 
> JAMES suffers from everyone doing anything interesting in the sandbox.
> this is bad. the reasoning behind the modular build is that anyone
> should be able to try new stuff without having to fork JAMES. that's
> now easy in trunk.

ATM JAMES suffers from everyone doing nothing :-(
The sandbox ERA is already past.. it lasted few months...
As I said I would hate moving IMAP to sandbox. It was simply a statement 
to tell you what I would "accept" without a -1. If I understood it 
correctly you was fine with keeping IMAP in trunk or moving it to 
svn/james/imapserver, am I wrong? (I just didn't like the 
svn/james/server/imapserver solution, but I hope this is a minor 
technical detail)

>>> i think that the lack of releases is unhealthy for the community. i
>>> also understand that many developers feel frustrated. i see no reasons
>>> why JAMES couldn't release a couple of components a month for the next
>>> year or so provided that the people who want more releases step
>>> forward.
>>>
>>  I think you understand that when this community try for real and concretely
>> to release something I always try to help someway (site stuff, release
>> tests, maven issues). Just don't ask me to push things. I gave up with
>> pushing :-) . I will join when I see something I consider concrete and
>> realistic.
> 
> if no one's willing to push forward releases then they aren't going to
> happen. previously, you were pushing against too many in the community
> to have a realistic chance of success. the art is to approach from a
> different perspective.

Have you understood WHO was against and WHY? I'm still waiting to 
understand why and to get counterproposal or to get some "sorry, I was 
wrong, please try again now". Sometimes it is good to read again that 
old messages. Read the motivations.. people was scared because they need 
some more months to complete their work... I guess they had their months 
now, maybe now everything is ok to release ;-)
I still hope you will try to push, because if you don't do this, no one 
else will do now. I don't expect anymore the community that complained 
me and Norman at the end of 2006 to get a better solution to our 
proposal (I checked my spam folder and is not there ;-) ).

> i think releasing mailet-api, mailet-base, std-mailet and crypto-mail
> in the next month is not unrealistic if someone else were to step
> forward to act as release manager so we can spread the load. we will
> then have started to release the 3.0 code base in a way that allow
> it's encorporation within the 2.x codebase.

I will not do the release manager, but I can try helping with mailets 
and coping with dependencies and code analysis as I did in the original 
message identifying what mailets/matchers can be moved or not and why.

> there is a lot of interest in lightweight, embeddable protocol
> handling libraries. one way to reassemble JAMES would be to extract
> our popular protocol into separate products. we then build the
> headline JAMES server from loosely coupled components with separate
> versioning. the more i look at the codebase, the more i think that if
> only avalon were not so intrusive this would be a realistic
> possibility. this would allow SMTP to be released when it were ready
> and arguments about that protocol to be restricted just to that
> codebase. it would also allow JAMES components to be easily reused in
> other projects (there are several who would be interested if only
> JAMES were not so monolithic).
> 
> - robert

I don't consider JAMES a so big monolithic application. IMHO JAMES has a 
small-medium codebase. I'm used to work on much larger source trees and 
I don't feel this need to break things apart (but I guess you already 
got this ;-) ).

That said I'm working on avalon free, seda based, protocols libraries 
outside ASF/JAMES so I really agree on the rest of your sentence.

The more we talk, the more I think you're simply late (wrt JAMES 
involvement) and that if you was here 2 years ago we would have james 
*4.0* out now!

Stefano

PS: OK, I realize I should not consume so much of your time. My "bar 
discussions" are not concrete steps to release.


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] trunk -= IMAP/Mailbox source...?

[Robert Burrell Donkin <ro...@gmail.com>]

On Mon, Apr 28, 2008 at 7:21 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>
> >
> > On Mon, Apr 28, 2008 at 1:20 PM, Stefano Bagnara <ap...@bago.org> wrote:
> >
> >
> > >  This make sense, BUT, who will be interested in releasing trunk after
> IMAP
> > > is removed?
> > >
> >
> > who's interested in releasing IMAP? not me, for one. i can live very
> > happily enough without any releases for the forseeable future.
> > releases attract users, not developers.
> >
>
>  True. Just take into consideration that many JAMES developers knew JAMES as
> users and then decided to start hacking the code.
>  1) Releases attract users that could be future developers
>  2) Releases give some developers motivations/satisfaction to keep working.

i don't have the energy to cope with users. even developers are
difficult since the codebase is in flux...

>  I, for one, started as an user of the 2.1 and then 2.2 and then I've had to
> fix/change a lot of code and decided to try to be a developer, I'm very
> happy for 2.3.0, and then I stopped because I had no enough
> energy/motivation to make another release like that one and I see no way to
> release again. But this is me. And this is past.

i don't have the energy to do everything. i can see a route towards
new JAMES releases involving considerable code from trunk if not trunk
itself. i just can't see any chance of releasing trunk at all. but if
no one else who wants releases has energy to contribute then i'm not
going waste my time.

> > IMAP is orthogonal to the community issues surrounding trunk. IMAP is
> > not tightly coupled to the rest of JAMES. if the community issues
> > remain unresolved when IMAP is ready for release, the easiest approach
> > would be to backport to a uncontroversial version.
> >
> > the only way that trunk is going to get released is if someone steps
> forward
> >
>
>  I agree. What I didn't agree is that removing IMAP is a step forward and
> that this is a community opinion.

i never said removing IMAP is the majority opinion: it's bound to be unpopular

> But I already said that I trust you on
> this. I will not -1 this.
>  If this is needed then let's make another "top level" project,
> svn/james/imapserver (with no weird trees, please ;-) ), or let's push back
> to sandbox (I would hate this, but if THE COMMUNITY think it is better, I
> will not vote down this too).

JAMES suffers from everyone doing anything interesting in the sandbox.
this is bad. the reasoning behind the modular build is that anyone
should be able to try new stuff without having to fork JAMES. that's
now easy in trunk.

> > i think that the lack of releases is unhealthy for the community. i
> > also understand that many developers feel frustrated. i see no reasons
> > why JAMES couldn't release a couple of components a month for the next
> > year or so provided that the people who want more releases step
> > forward.
> >
>
>  I think you understand that when this community try for real and concretely
> to release something I always try to help someway (site stuff, release
> tests, maven issues). Just don't ask me to push things. I gave up with
> pushing :-) . I will join when I see something I consider concrete and
> realistic.

if no one's willing to push forward releases then they aren't going to
happen. previously, you were pushing against too many in the community
to have a realistic chance of success. the art is to approach from a
different perspective.

i think releasing mailet-api, mailet-base, std-mailet and crypto-mail
in the next month is not unrealistic if someone else were to step
forward to act as release manager so we can spread the load. we will
then have started to release the 3.0 code base in a way that allow
it's encorporation within the 2.x codebase.

there is a lot of interest in lightweight, embeddable protocol
handling libraries. one way to reassemble JAMES would be to extract
our popular protocol into separate products. we then build the
headline JAMES server from loosely coupled components with separate
versioning. the more i look at the codebase, the more i think that if
only avalon were not so intrusive this would be a realistic
possibility. this would allow SMTP to be released when it were ready
and arguments about that protocol to be restricted just to that
codebase. it would also allow JAMES components to be easily reused in
other projects (there are several who would be interested if only
JAMES were not so monolithic).

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] trunk -= IMAP/Mailbox source...?

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On Mon, Apr 28, 2008 at 1:20 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>  This make sense, BUT, who will be interested in releasing trunk after IMAP
>> is removed?
> 
> who's interested in releasing IMAP? not me, for one. i can live very
> happily enough without any releases for the forseeable future.
> releases attract users, not developers.

True. Just take into consideration that many JAMES developers knew JAMES 
as users and then decided to start hacking the code.
1) Releases attract users that could be future developers
2) Releases give some developers motivations/satisfaction to keep working.

I, for one, started as an user of the 2.1 and then 2.2 and then I've had 
to fix/change a lot of code and decided to try to be a developer, I'm 
very happy for 2.3.0, and then I stopped because I had no enough 
energy/motivation to make another release like that one and I see no way 
to release again. But this is me. And this is past.

> IMAP is orthogonal to the community issues surrounding trunk. IMAP is
> not tightly coupled to the rest of JAMES. if the community issues
> remain unresolved when IMAP is ready for release, the easiest approach
> would be to backport to a uncontroversial version.
> 
> the only way that trunk is going to get released is if someone steps forward

I agree. What I didn't agree is that removing IMAP is a step forward and 
that this is a community opinion. But I already said that I trust you on 
this. I will not -1 this.
If this is needed then let's make another "top level" project, 
svn/james/imapserver (with no weird trees, please ;-) ), or let's push 
back to sandbox (I would hate this, but if THE COMMUNITY think it is 
better, I will not vote down this too).

> i think that the lack of releases is unhealthy for the community. i
> also understand that many developers feel frustrated. i see no reasons
> why JAMES couldn't release a couple of components a month for the next
> year or so provided that the people who want more releases step
> forward.

I think you understand that when this community try for real and 
concretely to release something I always try to help someway (site 
stuff, release tests, maven issues). Just don't ask me to push things. I 
gave up with pushing :-) . I will join when I see something I consider 
concrete and realistic.

And THANK YOU for all your effort. If you was not here we should 
probably have closed JAMES.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] trunk -= IMAP/Mailbox source...?

[Robert Burrell Donkin <ro...@gmail.com>]

On Mon, Apr 28, 2008 at 1:20 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>
> > On Sat, Apr 26, 2008 at 1:20 PM, Stefano Bagnara <ap...@bago.org> wrote:
> >
> > > Robert Burrell Donkin ha scritto:
> > >
> > > > On Sat, Apr 26, 2008 at 12:51 AM, Stefano Bagnara <ap...@bago.org>
> wrote:
> > > >
> > > >
> > > >
> > > > >  IMHO there is no shame in releasing code marked as unstable
> together
> > > > >
> > > >
> > > with
> > >
> > > >
> > > > > stable code. We introduced modules also for this, didn't we?
> > > > >
> > > > >
> > > > yes but IMHO that's not an opinion shared by the majority of those
> > > > with binding VOTEs.
> > > >
> > > >
> > >  O
> > >  We all know that I'm not good understanding what people thinks,
> expecially
> > > the PMC members but, excluding Noel, I think I never read other comments
> > > about trunk being crap or anything else that led me thought that we had
> to
> > > remove imap in order to try to release from there.
> > >
> >
> > no one seems to have a practical interest in releasing trunk. until
> > someone steps up. trunk will not be released.
> >
>
>  This make sense, BUT, who will be interested in releasing trunk after IMAP
> is removed?

who's interested in releasing IMAP? not me, for one. i can live very
happily enough without any releases for the forseeable future.
releases attract users, not developers.

IMAP is orthogonal to the community issues surrounding trunk. IMAP is
not tightly coupled to the rest of JAMES. if the community issues
remain unresolved when IMAP is ready for release, the easiest approach
would be to backport to a uncontroversial version.

the only way that trunk is going to get released is if someone steps forward

i think that the lack of releases is unhealthy for the community. i
also understand that many developers feel frustrated. i see no reasons
why JAMES couldn't release a couple of components a month for the next
year or so provided that the people who want more releases step
forward.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] trunk -= IMAP/Mailbox source...?

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On Sat, Apr 26, 2008 at 1:20 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Sat, Apr 26, 2008 at 12:51 AM, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>>
>>>>  IMHO there is no shame in releasing code marked as unstable together
>> with
>>>> stable code. We introduced modules also for this, didn't we?
>>>>
>>> yes but IMHO that's not an opinion shared by the majority of those
>>> with binding VOTEs.
>>>
>>  O
>>  We all know that I'm not good understanding what people thinks, expecially
>> the PMC members but, excluding Noel, I think I never read other comments
>> about trunk being crap or anything else that led me thought that we had to
>> remove imap in order to try to release from there.
> 
> no one seems to have a practical interest in releasing trunk. until
> someone steps up. trunk will not be released.

This make sense, BUT, who will be interested in releasing trunk after 
IMAP is removed?

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] trunk -= IMAP/Mailbox source...?

[Robert Burrell Donkin <ro...@gmail.com>]

On Sat, Apr 26, 2008 at 1:20 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> >
> > On Sat, Apr 26, 2008 at 12:51 AM, Stefano Bagnara <ap...@bago.org> wrote:
> >
> >
> > >  IMHO there is no shame in releasing code marked as unstable together
> with
> > > stable code. We introduced modules also for this, didn't we?
> > >
> >
> > yes but IMHO that's not an opinion shared by the majority of those
> > with binding VOTEs.
> >
>  O
>  We all know that I'm not good understanding what people thinks, expecially
> the PMC members but, excluding Noel, I think I never read other comments
> about trunk being crap or anything else that led me thought that we had to
> remove imap in order to try to release from there.

no one seems to have a practical interest in releasing trunk. until
someone steps up. trunk will not be released.

i think that the code in trunk has a greater chance of being released
as compact libraries rather than a cohesive product. once enough
libraries have been released (and shared with the stable 2.4.x code
base) trunk may be small enough to release without overwhelming
effort.

JAMES needs more developers. the more developers JAMES attracts, the
greater the chance of releasing trunk. the size of the trunk is
proving a major barrier to bringing interested developers in and
getting them productive.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] trunk -= IMAP/Mailbox source...?

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On Sat, Apr 26, 2008 at 12:51 AM, Stefano Bagnara <ap...@bago.org> wrote:
>>  IMHO there is no shame in releasing code marked as unstable together with
>> stable code. We introduced modules also for this, didn't we?
> 
> yes but IMHO that's not an opinion shared by the majority of those
> with binding VOTEs.

We all know that I'm not good understanding what people thinks, 
expecially the PMC members but, excluding Noel, I think I never read 
other comments about trunk being crap or anything else that led me 
thought that we had to remove imap in order to try to release from there.

BTW if you think the majority has a different opinion you for sure 
dedicated much more time to listen others than me, so I'll trust you.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] trunk -= IMAP/Mailbox source...?

[Robert Burrell Donkin <ro...@gmail.com>]

On Sat, Apr 26, 2008 at 12:51 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann ha scritto:
>
>
> >
> > > JAMES has no problem attracting developers: every month, someone shows
> > > up with a particular aim or interest. JAMES has a major issue
> > > converting developers into committers. IMHO the problem is that JAMES
> > > is too big and it takes too long to understand. you've got to be
> > > really dedicated even to start work on it.
> > >
> >
> > I think - or at least thought at first - that moving IMAP out of trunk is
> very unfortunate.
> > But let's also be pragmatic! If making trunk leaner helps us releasing,
> let's do it. Let's at least _try_ it. If it doesn't work out, we revert it.
> If later we want to have IMAP in as an experimental, disabled-by-default
> module, ok. But that's for later.
> >
>
>  I thought that having modules allowed us to keep working on a single source
> tree.

i would do but unfortunately, only Bernd and I seem interested in development

>  I don't understand who is convinced that moving IMAP out of trunk is what
> is needed to release.

i am convinced that we need to reduce the quantity of code that needs
to be reviewed before any releases can be made. IMAP-mailbox is the
majority of the codebase.

>  IMHO there is no shame in releasing code marked as unstable together with
> stable code. We introduced modules also for this, didn't we?

yes but IMHO that's not an opinion shared by the majority of those
with binding VOTEs. i suspect that if developer had the energy to
devote to rationally review the codebases in details then i suspect
that trunk is ok and that with some work a good 3.0 could be created
from it. however, the energy is just too great for this to be
realistic.

i think it's clear now that i've failed to attract a critcial mass of
developers to trunk. time to try a new approach, i think.

JAMES as a community needs to start releasing code again. it's clear
to me that there is no prospect of big releases but i think that a
program of small releases is definitely doable. i don't think that it
would be unrealistic to see mailet-api, mailet-base and sieve released
next month followed by standard-mailets, mime4j and crypto-mailets the
next then we could try a 2.3.x release containing the new libraries.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] trunk -= IMAP/Mailbox source...?

[Stefano Bagnara <ap...@bago.org>]

Bernd Fondermann ha scritto:
>> JAMES has no problem attracting developers: every month, someone shows
>> up with a particular aim or interest. JAMES has a major issue
>> converting developers into committers. IMHO the problem is that JAMES
>> is too big and it takes too long to understand. you've got to be
>> really dedicated even to start work on it.
> 
> I think - or at least thought at first - that moving IMAP out of trunk 
> is very unfortunate.
> But let's also be pragmatic! If making trunk leaner helps us releasing, 
> let's do it. Let's at least _try_ it. If it doesn't work out, we revert 
> it. If later we want to have IMAP in as an experimental, 
> disabled-by-default module, ok. But that's for later.

I thought that having modules allowed us to keep working on a single 
source tree.

I don't understand who is convinced that moving IMAP out of trunk is 
what is needed to release.

IMHO there is no shame in releasing code marked as unstable together 
with stable code. We introduced modules also for this, didn't we?

> For now let's trust and support those who take reasonable action.
> Let's not wait paralized for the branch who never comes, or the big 
> trunk-cleanup which everybody is too scared to do.
> Please support those (Robert, in this case) who act today.
> Following his proposal we have nothing to loose, really. But if it works 
> out, we win a lot.

You probably can't understand how long I hoped to read something similar 
on this list.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] trunk -= IMAP/Mailbox source...?

[Robert Burrell Donkin <ro...@gmail.com>]

On Thu, Apr 24, 2008 at 8:33 PM, Bernd Fondermann <bf...@brainlounge.de> wrote:
>
> Robert Burrell Donkin wrote:
>
> > On Thu, Apr 24, 2008 at 7:06 PM, Stefano Bagnara <ap...@bago.org> wrote:
> >
> > > Robert Burrell Donkin ha scritto:

<snip>

> > > Making a tree with 1000 simple leafs will not make developers life
> easier.
> > > They instead will loose much more time trying to understand what project
> > > calls a given method or what project contains a given feature they want
> to
> > > alter/fix/test.
> > >
> >
> > it's not about splitting into 1000 simple leafs but about factoring
> > out meaningful components without complex dependencies
> >
> > JAMES has no problem attracting developers: every month, someone shows
> > up with a particular aim or interest. JAMES has a major issue
> > converting developers into committers. IMHO the problem is that JAMES
> > is too big and it takes too long to understand. you've got to be
> > really dedicated even to start work on it.
> >
>
>  I think - or at least thought at first - that moving IMAP out of trunk is
> very unfortunate.
>  But let's also be pragmatic! If making trunk leaner helps us releasing,
> let's do it. Let's at least _try_ it. If it doesn't work out, we revert it.
> If later we want to have IMAP in as an experimental, disabled-by-default
> module, ok. But that's for later.
>
>  For now let's trust and support those who take reasonable action.
>  Let's not wait paralized for the branch who never comes, or the big
> trunk-cleanup which everybody is too scared to do.

i'd probably use fork and delete: just take a copy of trunk and then
delete everything that isn't IMAP related and see how far this gets so
it's initially low risk but it does means that IMAP development will
have to stop in trunk till the forks either succeeds or fails...

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] trunk -= IMAP/Mailbox source...?

[Bernd Fondermann <bf...@brainlounge.de>]

Robert Burrell Donkin wrote:
> On Thu, Apr 24, 2008 at 7:06 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Thu, Apr 24, 2008 at 2:47 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>> Robert Burrell Donkin ha
>>>>> there's a lot of code in IMAP-Mailbox. this creates a large barrier to
>>>>> entry both for developers wanting to work on IMAP-Maibox and for
>>>>> developers who want to work on other components.
>>>>>
>>>>> i'd like to think about moving the whole of the IMAP-mailbox code base
>>>>> out of server/trunk and into server/protocols/imap/trunk (say). this
>>>>> move would include the sieve mailet.
>>>>>
>>>>>
>>>>  -0. I don't think that disgregation of code will help: we already moved
>>>> mailet outside from james server. We made james server modular. I want
>> to
>>>> see some releases before any other disgregation is done. I'd like to see
>>>> proofs that this road works for real before following it so much.
>>>>
>>> face facts: JAMES trunk is never going to be released - there just
>>> isn't enough agreement within the developers. so we should aim to
>>> factor out and release what we can agree on.
>>>
>>> it's easy to have releases provided that the code released is in the
>>> form of libraries of reasonable size
>>>
>>  Right, but I don't really see how having IMAP-Mailbox in an external
>> library will make it easier to release JAMES server.
> 
> in the short term, it won't but then again, i see no prospect of
> releasing trunk any time soon
> 
>>  Either you remove all the modules that will depened on IMAP-Mailbox or you
>> will need to release IMAP-Mailbox BEFORE being able to release JAMES server.
> 
> i plan to remove all modules that depend on IMAP-mailbox other than
> the deployment ones. if IMAP is not released when the time comes for a
> server release then the jars can be removed from stage during the
> final push.
> 
>> About the agreement within the developers: have you understood something
>> there is agreement upon?
> 
> i've been no evidence during the time i've been involved in JAMES that
> there is any collective agreement on direction. small groups of
> developers have overlapping interests but no collective vision. so,
> let's start working together on what we agree on and then let the
> vision take care of itself.
> 
>>  Do you think that extracting more libraries to their own modules will make
>> it easier to have a release soon? How?
> 
> 1. by getting the JAMES team back into the habit by releasing small,
> useful libraries
> 2. by making it easier to remove components which aren't stable enough
> to be released right now
> 3. by making it easier for developers to get involved in JAMES by
> allowing them to work on small, useful codebases
> 4. by allowing code to be tested in production
> 5. by allowing code to be shared between versions
> 
>>>>  Releases should be the goal, and in the last year we only had 2 jSPF
>>>> releases and nothing else :-((
>>>>
>>> if you want more releases, step forward
>>>
>>  Sorry but Norman and I already did it 17 months ago with a very concrete
>> proposal but we failed. Nothing changed since that time, so I don't really
>> see why it should work now.
> 
> then start small: there are components which could be released
> 
>>>>  Is IMAP-mailbox a standalone library? Has it any use separated from
>> JAMES
>>>> Server code? Is there any developer working on that code lamenting the
>> issue
>>>> of having to work with the whole "server" checked out?
>>>>
>>> yes (or should be), yes (service, axis, geronimo) and yes (happened a
>>> couple of weeks ago, also noel reported to me that lots of people have
>>> had issues)
>>>
>>  Sorry but I don't get it: "james-server-imapmailbox-library" is currently
>> *3* classes for a total of 33KB of java sources: does this really require an
>> *external* module ??? Maybe instead you are talking about more modules? In
>> this case can you make an explicit list?
> 
> i propose the complete removal of all code related to mailbox and IMAP
> (old and new). lots of modules and half of core.
> 
>>>> Furhermore at "server" level we already have the TTB structure
>>>> (trunk/tags/branches), I will probably -1 adding a "protocol" folder at
>> the
>>>> same level. IMHO it is against the least surprise principle.
>>>>
>>> just saves moving stuff down a level. also server/server doesn't make
>>> much sense to me
>>>
>>> - robert
>>>
>> Making a tree with 1000 simple leafs will not make developers life easier.
>> They instead will loose much more time trying to understand what project
>> calls a given method or what project contains a given feature they want to
>> alter/fix/test.
> 
> it's not about splitting into 1000 simple leafs but about factoring
> out meaningful components without complex dependencies
> 
> JAMES has no problem attracting developers: every month, someone shows
> up with a particular aim or interest. JAMES has a major issue
> converting developers into committers. IMHO the problem is that JAMES
> is too big and it takes too long to understand. you've got to be
> really dedicated even to start work on it.

I think - or at least thought at first - that moving IMAP out of trunk 
is very unfortunate.
But let's also be pragmatic! If making trunk leaner helps us releasing, 
let's do it. Let's at least _try_ it. If it doesn't work out, we revert 
it. If later we want to have IMAP in as an experimental, 
disabled-by-default module, ok. But that's for later.

For now let's trust and support those who take reasonable action.
Let's not wait paralized for the branch who never comes, or the big 
trunk-cleanup which everybody is too scared to do.

Please support those (Robert, in this case) who act today.
Following his proposal we have nothing to loose, really. But if it works 
out, we win a lot.



   Bernd




---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] trunk -= IMAP/Mailbox source...?

[Robert Burrell Donkin <ro...@gmail.com>]

On Thu, Apr 24, 2008 at 8:23 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>
> >
> > >  Either you remove all the modules that will depened on IMAP-Mailbox or
> you
> > >
> > > will need to release IMAP-Mailbox BEFORE being able to release JAMES
> server.
> > >
> >
> >
> > i plan to remove all modules that depend on IMAP-mailbox other than
> > the deployment ones. if IMAP is not released when the time comes for a
> > server release then the jars can be removed from stage during the
> > final push.
> >
>  [...]
>
>
> >
> > >  Sorry but I don't get it: "james-server-imapmailbox-library" is
> currently
> > > *3* classes for a total of 33KB of java sources: does this really
> require an
> > > *external* module ??? Maybe instead you are talking about more modules?
> In
> > > this case can you make an explicit list?
> > >
> >
> > i propose the complete removal of all code related to mailbox and IMAP
> > (old and new). lots of modules and half of core.
> >
>
>  So your "IMAP/Mailbox" in the title was referring to "all the IMAP API,
> libraries and functions modules, including the mailbox ones." and not the
> "imapmailbox-library" module as I took it. Is this correct?
>
>  This means you would split "JAMES Server" into 2 projects by moving the
> following modules to a new multimodule project depending on some of the
> JAMES Server modules:
>  imap-mailbox-processor-function
>  imapmailbox-library
>  torque-mailboxmanager-function
>  imapserver-function
>  imap-codec-library
>  imap-command-library
>  imap-api
>  experimental-seda-imap-function
>
>  Is this correct?

more or less

plus the mailbox API from core

> In this case sorry for the previous reply, as I totally
> got it wrong ;-) In this case I have to think a bit more about it...

of course: i wanted to announce the idea so that people can get used to it

>  Furthermore the new project would depend on JAMES Server and not viceversa,
> right?

no

with a little refactoring i think i can break the essential
co-dependency into a very small number of interface classes. i propose
to introduce a minimal SPI to hold these interfaces. some glue code
will be required in deployment coupled to both IMAP and JAMES but the
functions in the server and IMAP will be coupled only by a minimal
interface.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] trunk -= IMAP/Mailbox source...?

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
>>  Either you remove all the modules that will depened on IMAP-Mailbox or you
>> will need to release IMAP-Mailbox BEFORE being able to release JAMES server.
> 
> i plan to remove all modules that depend on IMAP-mailbox other than
> the deployment ones. if IMAP is not released when the time comes for a
> server release then the jars can be removed from stage during the
> final push.
[...]
>>  Sorry but I don't get it: "james-server-imapmailbox-library" is currently
>> *3* classes for a total of 33KB of java sources: does this really require an
>> *external* module ??? Maybe instead you are talking about more modules? In
>> this case can you make an explicit list?
> 
> i propose the complete removal of all code related to mailbox and IMAP
> (old and new). lots of modules and half of core.

So your "IMAP/Mailbox" in the title was referring to "all the IMAP API, 
libraries and functions modules, including the mailbox ones." and not 
the "imapmailbox-library" module as I took it. Is this correct?

This means you would split "JAMES Server" into 2 projects by moving the 
following modules to a new multimodule project depending on some of the 
JAMES Server modules:
imap-mailbox-processor-function
imapmailbox-library
torque-mailboxmanager-function
imapserver-function
imap-codec-library
imap-command-library
imap-api
experimental-seda-imap-function

Is this correct? In this case sorry for the previous reply, as I totally 
got it wrong ;-) In this case I have to think a bit more about it...

Furthermore the new project would depend on JAMES Server and not 
viceversa, right?

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] trunk -= IMAP/Mailbox source...?

[Robert Burrell Donkin <ro...@gmail.com>]

On Thu, Apr 24, 2008 at 7:06 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On Thu, Apr 24, 2008 at 2:47 PM, Stefano Bagnara <ap...@bago.org> wrote:
> > > Robert Burrell Donkin ha
> > > > there's a lot of code in IMAP-Mailbox. this creates a large barrier to
> > > > entry both for developers wanting to work on IMAP-Maibox and for
> > > > developers who want to work on other components.
> > > >
> > > > i'd like to think about moving the whole of the IMAP-mailbox code base
> > > > out of server/trunk and into server/protocols/imap/trunk (say). this
> > > > move would include the sieve mailet.
> > > >
> > > >
> > >  -0. I don't think that disgregation of code will help: we already moved
> > > mailet outside from james server. We made james server modular. I want
> to
> > > see some releases before any other disgregation is done. I'd like to see
> > > proofs that this road works for real before following it so much.
> > >
> >
> > face facts: JAMES trunk is never going to be released - there just
> > isn't enough agreement within the developers. so we should aim to
> > factor out and release what we can agree on.
> >
> > it's easy to have releases provided that the code released is in the
> > form of libraries of reasonable size
> >
>
>  Right, but I don't really see how having IMAP-Mailbox in an external
> library will make it easier to release JAMES server.

in the short term, it won't but then again, i see no prospect of
releasing trunk any time soon

>  Either you remove all the modules that will depened on IMAP-Mailbox or you
> will need to release IMAP-Mailbox BEFORE being able to release JAMES server.

i plan to remove all modules that depend on IMAP-mailbox other than
the deployment ones. if IMAP is not released when the time comes for a
server release then the jars can be removed from stage during the
final push.

> About the agreement within the developers: have you understood something
> there is agreement upon?

i've been no evidence during the time i've been involved in JAMES that
there is any collective agreement on direction. small groups of
developers have overlapping interests but no collective vision. so,
let's start working together on what we agree on and then let the
vision take care of itself.

>  Do you think that extracting more libraries to their own modules will make
> it easier to have a release soon? How?

1. by getting the JAMES team back into the habit by releasing small,
useful libraries
2. by making it easier to remove components which aren't stable enough
to be released right now
3. by making it easier for developers to get involved in JAMES by
allowing them to work on small, useful codebases
4. by allowing code to be tested in production
5. by allowing code to be shared between versions

> > >  Releases should be the goal, and in the last year we only had 2 jSPF
> > > releases and nothing else :-((
> > >
> >
> > if you want more releases, step forward
> >
>
>  Sorry but Norman and I already did it 17 months ago with a very concrete
> proposal but we failed. Nothing changed since that time, so I don't really
> see why it should work now.

then start small: there are components which could be released

> > >  Is IMAP-mailbox a standalone library? Has it any use separated from
> JAMES
> > > Server code? Is there any developer working on that code lamenting the
> issue
> > > of having to work with the whole "server" checked out?
> > >
> >
> > yes (or should be), yes (service, axis, geronimo) and yes (happened a
> > couple of weeks ago, also noel reported to me that lots of people have
> > had issues)
> >
>
>  Sorry but I don't get it: "james-server-imapmailbox-library" is currently
> *3* classes for a total of 33KB of java sources: does this really require an
> *external* module ??? Maybe instead you are talking about more modules? In
> this case can you make an explicit list?

i propose the complete removal of all code related to mailbox and IMAP
(old and new). lots of modules and half of core.

> > > Furhermore at "server" level we already have the TTB structure
> > > (trunk/tags/branches), I will probably -1 adding a "protocol" folder at
> the
> > > same level. IMHO it is against the least surprise principle.
> > >
> >
> > just saves moving stuff down a level. also server/server doesn't make
> > much sense to me
> >
> > - robert
> >
>
> Making a tree with 1000 simple leafs will not make developers life easier.
> They instead will loose much more time trying to understand what project
> calls a given method or what project contains a given feature they want to
> alter/fix/test.

it's not about splitting into 1000 simple leafs but about factoring
out meaningful components without complex dependencies

JAMES has no problem attracting developers: every month, someone shows
up with a particular aim or interest. JAMES has a major issue
converting developers into committers. IMHO the problem is that JAMES
is too big and it takes too long to understand. you've got to be
really dedicated even to start work on it.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] trunk -= IMAP/Mailbox source...?

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On Thu, Apr 24, 2008 at 2:47 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>
>>
>>> there's a lot of code in IMAP-Mailbox. this creates a large barrier to
>>> entry both for developers wanting to work on IMAP-Maibox and for
>>> developers who want to work on other components.
>>>
>>> i'd like to think about moving the whole of the IMAP-mailbox code base
>>> out of server/trunk and into server/protocols/imap/trunk (say). this
>>> move would include the sieve mailet.
>>>
>>  -0. I don't think that disgregation of code will help: we already moved
>> mailet outside from james server. We made james server modular. I want to
>> see some releases before any other disgregation is done. I'd like to see
>> proofs that this road works for real before following it so much.
> 
> face facts: JAMES trunk is never going to be released - there just
> isn't enough agreement within the developers. so we should aim to
> factor out and release what we can agree on.
> 
> it's easy to have releases provided that the code released is in the
> form of libraries of reasonable size

Right, but I don't really see how having IMAP-Mailbox in an external 
library will make it easier to release JAMES server.
Either you remove all the modules that will depened on IMAP-Mailbox or 
you will need to release IMAP-Mailbox BEFORE being able to release JAMES 
server.

About the agreement within the developers: have you understood something 
there is agreement upon?

Do you think that extracting more libraries to their own modules will 
make it easier to have a release soon? How?

>>  Releases should be the goal, and in the last year we only had 2 jSPF
>> releases and nothing else :-((
> 
> if you want more releases, step forward

Sorry but Norman and I already did it 17 months ago with a very concrete 
proposal but we failed. Nothing changed since that time, so I don't 
really see why it should work now.

>>  Is IMAP-mailbox a standalone library? Has it any use separated from JAMES
>> Server code? Is there any developer working on that code lamenting the issue
>> of having to work with the whole "server" checked out?
> 
> yes (or should be), yes (service, axis, geronimo) and yes (happened a
> couple of weeks ago, also noel reported to me that lots of people have
> had issues)

Sorry but I don't get it: "james-server-imapmailbox-library" is 
currently *3* classes for a total of 33KB of java sources: does this 
really require an *external* module ??? Maybe instead you are talking 
about more modules? In this case can you make an explicit list?

Developers interested in JAMES should better write messages to 
server-dev. If people speaks with Noel can't be listened by me and other 
PMC members. So please ask them to write to this list, so we can 
understand what exactly is their issue.

>> Furhermore at "server" level we already have the TTB structure
>> (trunk/tags/branches), I will probably -1 adding a "protocol" folder at the
>> same level. IMHO it is against the least surprise principle.
> 
> just saves moving stuff down a level. also server/server doesn't make
> much sense to me
> 
> - robert

Making a tree with 1000 simple leafs will not make developers life 
easier. They instead will loose much more time trying to understand what 
project calls a given method or what project contains a given feature 
they want to alter/fix/test.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] trunk -= IMAP/Mailbox source...?

[Robert Burrell Donkin <ro...@gmail.com>]

On Thu, Apr 24, 2008 at 2:47 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>
>
> > there's a lot of code in IMAP-Mailbox. this creates a large barrier to
> > entry both for developers wanting to work on IMAP-Maibox and for
> > developers who want to work on other components.
> >
> > i'd like to think about moving the whole of the IMAP-mailbox code base
> > out of server/trunk and into server/protocols/imap/trunk (say). this
> > move would include the sieve mailet.
> >
>
>  -0. I don't think that disgregation of code will help: we already moved
> mailet outside from james server. We made james server modular. I want to
> see some releases before any other disgregation is done. I'd like to see
> proofs that this road works for real before following it so much.

face facts: JAMES trunk is never going to be released - there just
isn't enough agreement within the developers. so we should aim to
factor out and release what we can agree on.

it's easy to have releases provided that the code released is in the
form of libraries of reasonable size

>  Releases should be the goal, and in the last year we only had 2 jSPF
> releases and nothing else :-((

if you want more releases, step forward

>  Is IMAP-mailbox a standalone library? Has it any use separated from JAMES
> Server code? Is there any developer working on that code lamenting the issue
> of having to work with the whole "server" checked out?

yes (or should be), yes (service, axis, geronimo) and yes (happened a
couple of weeks ago, also noel reported to me that lots of people have
had issues)

> Furhermore at "server" level we already have the TTB structure
> (trunk/tags/branches), I will probably -1 adding a "protocol" folder at the
> same level. IMHO it is against the least surprise principle.

just saves moving stuff down a level. also server/server doesn't make
much sense to me

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] trunk -= IMAP/Mailbox source...?

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> there's a lot of code in IMAP-Mailbox. this creates a large barrier to
> entry both for developers wanting to work on IMAP-Maibox and for
> developers who want to work on other components.
> 
> i'd like to think about moving the whole of the IMAP-mailbox code base
> out of server/trunk and into server/protocols/imap/trunk (say). this
> move would include the sieve mailet.

-0. I don't think that disgregation of code will help: we already moved 
mailet outside from james server. We made james server modular. I want 
to see some releases before any other disgregation is done. I'd like to 
see proofs that this road works for real before following it so much.

Releases should be the goal, and in the last year we only had 2 jSPF 
releases and nothing else :-((

Is IMAP-mailbox a standalone library? Has it any use separated from 
JAMES Server code? Is there any developer working on that code lamenting 
the issue of having to work with the whole "server" checked out?

Furhermore at "server" level we already have the TTB structure 
(trunk/tags/branches), I will probably -1 adding a "protocol" folder at 
the same level. IMHO it is against the least surprise principle.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org