Am Dienstag, den 12.09.2006, 21:44 -0400 schrieb Noel J. Bergman:
Stefano Bagnara wrote:
Noel J. Bergman wrote:
As I said long ago, if you want to move trunk to 2.4, we should
review every difference. Then, if we agree that each one
represents a suitable risk/reward, fine.
I'm sorry but (as I also said long ago) I'm on the opposite position
about the 2.4 roadmap.
So what is your position? That we should simply dump trunk on users without
proper review? Without comparing it to what we have spent so long testing
and reviewing in the 2.3 branch?
Well we should start testing the trunk ;-) (I have trunk running
allready on a testserver) So we can get sure its stable and fix bugs!
We've just finished with a lot of efforts to put out a stable release to
replace the old 2.2.0.
Exactly.
And it seems that is do a much better job. I agree.
Now I think that not only we should include everything we have now in
trunk, but we should also define a period of feature development where
we try to put in every cool feature we are able to develop in this time
with one single restriction: keep storage compatibility.
When do you expect to put that out?! I'm talking about a plan that allows
us to put out a stable release very few months with carefully made changes,
and you just want to core dump! I do not agree to that approach.
I don't agree with you both :-P
I think we need a roadmap and only workin on the code which include
features which listed in the roadmap. Bugs should be fixed too
When someone feel to work on a other task then one listed in the roadmap
he should raise his voice in the mailinglist and if we agree we put it
on the roadmap and include it. If not he should wait with the work and
wait for next release.
Like i said before i see no problems starting to workin on 2.4 and use
trunk as it is. I whould be happy if we could put out 2.4 in about 6
Month later then 2.3 is released.
My proposal is to start at least 2 months of free development in trunk
and then create the 2.4 branch to start the consolidation process.
And if we do it my way, we can release 2.4 in less than 2 months. And work
on v3 at the same time. And I want to branch soon, so that we can start
working on the major changes that we should be doing for v3, and not just
the safe but useful changes for v2.4.
See my comment above.
Everything we currently have in trunk deserve inclusion in the next
release and much more of this.
Wrong. Most of what is in trunk has had a fraction of the review and
testing that we have spent on v2.3, and you're talking about a free-for-all
of development.
See my comment above We need a roadmap.
Furthermore I would consider a big mistake to try to release 2.4 as a
2.3 + new fastfail things, because new fastfail things are still in
progress and not mature enough
And yet you want to use TRUNK as 2.4?! Be consistent. Trunk has many such
"still in progress and not mature enough" things, not just fast-fail. Maybe
we decide that fast-fail isn't mature enough yet. As you say:
I agree that we have stuff which is not 100% finish. So we need to focus
on that first! The handler api is one of the stuff we need to finish
first soon. Cause as longer we wait as harder it get to merge the
stuff.
There is a lot of stuff that has been removed by the 2.3 branch but
should really fit the 2.4 branch: database read/write streaming (we have
write streaming in 2.3 but disabled by default because we had no time to
test it enough), spool manager refactorings, 8bitmime (try again with
new javamail fixes). We should refactor pop3 to follow the same smtp
handlerchain pattern (and maybe do the same for remotemanager and nntp)
We could try to include easier virtualhosting support, support for APP
and much other features that don't introduce storage incompatibility
problems.
Not all of those share the same level of testing, value or urgency, and yet
you just want to dump it all on users as if we had carefully developed and
tested them?
Thats why we should try to test it again. It will never get stable if
noone tests. Please don't let us do the same mistake as in 2.3 We all
need to test it more. I have always a "trunk server" on a testsystem
which serve some not so importent stuff.
You've just ennumerated a whole raft of issues. We should examine each one
to decide if THAT SPECIFIC PIECE is stable enough to go into the release,
not conflate a dozen or more items.
So we can start with ones that we all agree ARE stable enough to go into
v2.4, and not just dump a load of immature code on top of our stable
release.
See other comments.
A last reason to not start a 2.4 branch now and to not start a selective
merge job is that we are not sure that 2.3.0 would not need a 2.3.1
release in a month
If we start v2.4 from v2.3, we don't need 2.3.1. 2.4 would be suffice. I
want to start using this stuff ASAP, not after another year of development
and testing.
Noel
I agree with Stefano And i think we can push a 2.4 release in 6 Month
( At least i hope so).
So i think the next step must a roadmap! First we should dedicide which
jira issues should be moved to 2.4 before do anything else. Without a
roadmap we only make it more complicated.
bye
Norman
PGP SIGNATURE
Version: GnuPG v1.4.2.2 (GNU/Linux)
XlgWHn7w1c6WhYeh9YGEBw=
=
PGP SIGNATURE

Norman Maurer wrote:
Now I think that not only we should include everything we have now in
trunk, but we should also define a period of feature development where
we try to put in every cool feature we are able to develop in this time
with one single restriction: keep storage compatibility.
>When do you expect to put that out?! I'm talking about a plan that allows
>us to put out a stable release very few months with carefully made changes,
>and you just want to core dump! I do not agree to that approach.
I don't agree with you both :-P
I think we need a roadmap and only workin on the code which include
features which listed in the roadmap. Bugs should be fixed too
When someone feel to work on a other task then one listed in the roadmap
he should raise his voice in the mailinglist and if we agree we put it
on the roadmap and include it. If not he should wait with the work and
wait for next release.
Like i said before i see no problems starting to workin on 2.4 and use
trunk as it is. I whould be happy if we could put out 2.4 in about 6
Month later then 2.3 is released.

Well, I think that we have not enough man-power and paid-work to define
a roadmap with dates and be sure we'll reach our goals. So we should
either define a feature set R a date for the branch. Imo if we want to
be sure we'll release in about 6 month we should start the consolidation
branch in 2-3 months from now.

So I think we should define a list of things that could be included and
things that must be postponed and then we'll have to accept what we have
in trunk when we branch.

Furthermore I would consider a big mistake to try to release 2.4 as a
2.3 + new fastfail things, because new fastfail things are still in
progress and not mature enough
>And yet you want to use TRUNK as 2.4?! Be consistent. Trunk has many such
>"still in progress and not mature enough" things, not just fast-fail. Maybe
>we decide that fast-fail isn't mature enough yet. As you say:

I agree that we have stuff which is not 100% finish. So we need to focus
on that first! The handler api is one of the stuff we need to finish
first soon. Cause as longer we wait as harder it get to merge the
stuff.

Right: if we define a date for the consolidation-branch then we can take
care than no unfinished stuff is in trunk by that day so that we won't
need to finish stuff in the branch but only to consolidate it.
Now it is simply unfeasible to branch 2.4 from trunk and finish the
fastfail work there. Imo if we wanted to branch today we should exclude
fastfail because it is still work in progress and we still have a
further proposal branch opened on that issue. So we only could include
very few things: JMX stuff, few mailets, few management commands, and
common daemon. I won't loose a "release cycle" for so few features.

A last reason to not start a 2.4 branch now and to not start a selective
merge job is that we are not sure that 2.3.0 would not need a 2.3.1
release in a month
>If we start v2.4 from v2.3, we don't need 2.3.1. 2.4 would be suffice. I
>want to start using this stuff ASAP, not after another year of development
>and testing.
> Noel
>>
>>
I agree with Stefano And i think we can push a 2.4 release in 6 Month
( At least i hope so).

So i think the next step must a roadmap! First we should dedicide which
jira issues should be moved to 2.4 before do anything else. Without a
roadmap we only make it more complicated.

My proposal is:
- everything we have in trunk now: now I can't see anything critical
enough to be removed.
- JAMES-426 - Make james use virtual user table domains for servernames
- JAMES-52 - 8bitmime capabilities missing
- JAMES-487 - Refactor Bundled handlers to use the "HandlerChain" pattern
- JAMES-577 - Switch default sendpartial to true for RemoteDelivery
- JAMES-607 - Rewrite MBoxMailRepository to use mstor
- JAMES-611 - Remove finalizers and make sure we always call dispose
when unreferencing objects
- JAMES-461 - Javamail Store based MailRepository support (was: Maildir
support)
- JAMES-614 - Add more actions to FastFailHandlers
- JAMES-549 - Refactoring SMTPHandler to allow better integration of
more the one class per command
- JAMES-599 - BeanShell Scripting in James
- JAMES-562 - Aliasmanagment should not depend on a user (see as
VUT-UsersAliasingForwarding common interface and remove tightly
dependencies between James and JamesUser)
- JAMES-595 - Change names of release artifacts to use james-server
instead of james.

As I said if some of them will not be ready it won't be included: time
based roadmap is good if we have a good amount of
"new-feature-development" time in the release cycles.

things that I would like to see there if we find the time:
- JAMES-491 - SpoolManager refactorings
- JAMES-126 - Add support for APP authentication protocol
- JAMES-551 - Use MINA as framework
- JAMES-493 - Refactor James components/services to simplify their usage
in other IoC containers (SDI)
- JAMES-521 - Mail/Spool/Message repositories refactoring : there is a
message 1 year old and another few months old about how to work on this
while keeping storage compatibility.
- JAMES-288 - memory efficient retrieval
- JAMES-241 - fail gracefully upon large messages/attachments
- JAMES-134 - Large emails in the spool cause SpoolManager to throw
MemoryError
- JAMES-334 - SHA hash incompatable with common generation methods
- JAMES-332 - Support other digest algorithm (was: SHA hard coded in
adduser)
- JAMES-126 - Add support for APP authentication protocol

So there is no real distinction between the first list and the second
one: as I said I think that everything I listed deserve inclusion in 2.4
and does not break storage compatibility and neither needs major
refactorings, the main constraint is the time. I expect to actually be
able to work on many of the issues on the first list but I hope to find
the time for the second list.

Stefano

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

Am Mittwoch, den 13.09.2006, 10:13 +0200 schrieb Stefano Bagnara:
Norman Maurer wrote:
Now I think that not only we should include everything we have now in
trunk, but we should also define a period of feature development where
we try to put in every cool feature we are able to develop in this time
with one single restriction: keep storage compatibility.
>When do you expect to put that out?! I'm talking about a plan that allows
>us to put out a stable release very few months with carefully made changes,
>and you just want to core dump! I do not agree to that approach.
I don't agree with you both :-P
I think we need a roadmap and only workin on the code which include
features which listed in the roadmap. Bugs should be fixed too
When someone feel to work on a other task then one listed in the roadmap
he should raise his voice in the mailinglist and if we agree we put it
on the roadmap and include it. If not he should wait with the work and
wait for next release.
Like i said before i see no problems starting to workin on 2.4 and use
trunk as it is. I whould be happy if we could put out 2.4 in about 6
Month later then 2.3 is released.

Well, I think that we have not enough man-power and paid-work to define
a roadmap with dates and be sure we'll reach our goals. So we should
either define a feature set R a date for the branch. Imo if we want to
be sure we'll release in about 6 month we should start the consolidation
branch in 2-3 months from now.
Agree. We should define a list of features we want to include. Maybe
with prio. Then after a period we must dedicide what todo if we want to
release it soon we can remove tasks if not we can focus on a new date. I
think a release date is "importend".

So I think we should define a list of things that could be included and
things that must be postponed and then we'll have to accept what we have
in trunk when we branch.

agree.

Furthermore I would consider a big mistake to try to release 2.4 as a
2.3 + new fastfail things, because new fastfail things are still in
progress and not mature enough
>And yet you want to use TRUNK as 2.4?! Be consistent. Trunk has many such
>"still in progress and not mature enough" things, not just fast-fail. Maybe
>we decide that fast-fail isn't mature enough yet. As you say:

I agree that we have stuff which is not 100% finish. So we need to focus
on that first! The handler api is one of the stuff we need to finish
first soon. Cause as longer we wait as harder it get to merge the
stuff.

Right: if we define a date for the consolidation-branch then we can take
care than no unfinished stuff is in trunk by that day so that we won't
need to finish stuff in the branch but only to consolidate it.
Now it is simply unfeasible to branch 2.4 from trunk and finish the
fastfail work there. Imo if we wanted to branch today we should exclude
fastfail because it is still work in progress and we still have a
further proposal branch opened on that issue. So we only could include
very few things: JMX stuff, few mailets, few management commands, and
common daemon. I won't loose a "release cycle" for so few features.
Same here.

A last reason to not start a 2.4 branch now and to not start a selective
merge job is that we are not sure that 2.3.0 would not need a 2.3.1
release in a month
>If we start v2.4 from v2.3, we don't need 2.3.1. 2.4 would be suffice I
>want to start using this stuff ASAP, not after another year of development
>and testing.
> Noel
>>
>>
I agree with Stefano And i think we can push a 2.4 release in 6 Month
( At least i hope so).

So i think the next step must a roadmap! First we should dedicide which
jira issues should be moved to 2.4 before do anything else. Without a
roadmap we only make it more complicated.

My proposal is:
- everything we have in trunk now: now I can't see anything critical
enough to be removed.
- JAMES-426 - Make james use virtual user table domains for servernames
- JAMES-52 - 8bitmime capabilities missing
I hope we can get this work with new javamail when its released.
- JAMES-487 - Refactor Bundled handlers to use the "HandlerChain" pattern
Thats a must.
- JAMES-577 - Switch default sendpartial to true for RemoteDelivery
- JAMES-607 - Rewrite MBoxMailRepository to use mstor
Im not sure about this now. For this we must get sure mstor is really
thread-safe!
- JAMES-611 - Remove finalizers and make sure we always call dispose
when unreferencing objects
- JAMES-461 - Javamail Store based MailRepository support (was: Maildir
support)
Joachim did a great work on this. Yes thats a must.
- JAMES-614 - Add more actions to FastFailHandlers
- JAMES-549 - Refactoring SMTPHandler to allow better integration of
more the one class per command
- JAMES-599 - BeanShell Scripting in James
- JAMES-562 - Aliasmanagment should not depend on a user (see as
VUT-UsersAliasingForwarding common interface and remove tightly
dependencies between James and JamesUser)
- JAMES-595 - Change names of release artifacts to use james-server
instead of james.

As I said if some of them will not be ready it won't be included: time
based roadmap is good if we have a good amount of
"new-feature-development" time in the release cycles.

things that I would like to see there if we find the time:
- JAMES-491 - SpoolManager refactorings
- JAMES-126 - Add support for APP authentication protocol
Don't think that is importent for many people. I whould delay this
- JAMES-551 - Use MINA as framework
Don't think that we will able to do this in 2.4
- JAMES-493 - Refactor James components/services to simplify their usage
in other IoC containers (SDI)
- JAMES-521 - Mail/Spool/Message repositories refactoring : there is a
message 1 year old and another few months old about how to work on this
while keeping storage compatibility.
- JAMES-288 - memory efficient retrieval
- JAMES-241 - fail gracefully upon large messages/attachments
- JAMES-134 - Large emails in the spool cause SpoolManager to throw
MemoryError
- JAMES-334 - SHA hash incompatable with common generation methods
- JAMES-332 - Support other digest algorithm (was: SHA hard coded in
adduser)
- JAMES-126 - Add support for APP authentication protocol
See above

So there is no real distinction between the first list and the second
one: as I said I think that everything I listed deserve inclusion in 2.4
and does not break storage compatibility and neither needs major
refactorings, the main constraint is the time. I expect to actually be
able to work on many of the issues on the first list but I hope to find
the time for the second list.

Stefano

I hope i will have some time and hope other commiters too
bye
Norman

PGP SIGNATURE
Version: GnuPG v1.4.2.2 (GNU/Linux)

WLHfq2HtRBfZtrupTVHXeSU=
=nuEx
PGP SIGNATURE

Slightly more than a month ago I wrote a roadmap, here is an update for
people that has not time for a day to day oversight.

Stefano Bagnara wrote:
Norman Maurer wrote:
>I agree with Stefano And i think we can push a 2.4 release in 6 Month
>( At least i hope so).
>>
>So i think the next step must a roadmap! First we should dedicide which
>jira issues should be moved to 2.4 before do anything else. Without a
>roadmap we only make it more complicated.

My proposal is:
- everything we have in trunk now: now I can't see anything critical
enough to be removed.

Well, this was already there ;-)
- JAMES-426 - Make james use virtual user table domains for servernames

This is done.
- JAMES-52 - 8bitmime capabilities missing

It seems that javamail 1.4.1ea fixed the problem and we reenabled the
support for it!
- JAMES-487 - Refactor Bundled handlers to use the "HandlerChain" pattern

This is blocked by the handlerapi work in sandbox.
- JAMES-577 - Switch default sendpartial to true for RemoteDelivery

Done.
- JAMES-607 - Rewrite MBoxMailRepository to use mstor

We wrote the support for this: Joachim found 3 blocking bugs in mstor. 2
of them have been fixed, so as soon as mstor will fix the third and make
a release this will be fixed.
- JAMES-611 - Remove finalizers and make sure we always call dispose
when unreferencing objects

Done.
- JAMES-461 - Javamail Store based MailRepository support (was: Maildir
support)

Joachim contributed this. Applied.
- JAMES-614 - Add more actions to FastFailHandlers

In progress: Norman is working on this.
- JAMES-549 - Refactoring SMTPHandler to allow better integration of
more the one class per command

Blocked by the new handlerapi in sandbox.
- JAMES-599 - BeanShell Scripting in James

Code has been provided by Guillermo.
We should probably vote to decide wethere to include this or not.
I wrote a message in past to understand wether there was preference for
this BeanShell solution or on the BSF mailet: I would like to see the
BSF mailet code before deciding, but I can't find it.
- JAMES-562 - Aliasmanagment should not depend on a user (see as
VUT-UsersAliasingForwarding common interface and remove tightly
dependencies between James and JamesUser)

Almost done.
- JAMES-595 - Change names of release artifacts to use james-server
instead of james.

(but easy to do).

That said, currenlty blocking issues are:

1) dnsjava 2.0.3 release (to support JSPF)
(we are currenlty including a snapshot of dnsjava trunk)

2) javamail 1.4.1 release (8bitmime bugs)
(we are currenlty including 1.4.1ea-SNAPSHT from their m2 repository)

3) mstor release (to replace internal mbox management with mstor)
(2 of 3 bugs have been fixed in cvs, so we should be able soon to
include a working snapshot or the fixed release)

4) handlerapi v2.
(If I understood it right, Noel is almost ready with his work)

I think that if we can comlpete the handlerapi stuff soon we could
realistically consider branching for a release at the start of december
(almost a month before what was in the plans)

Stefano

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

10/20/06, Stefano Bagnara <apache (AT) bago (DOT) orgwrote:
Slightly more than a month ago I wrote a roadmap, here is an update for
people that has not time for a day to day oversight.

Thanks Stefano ;-)

Can we consider timetabling some other changes now that we've made
such good progress?

1/ thing I have been trying to get "on the table" for a couple of
years(!) now is a re-write of the mailet API. We need to make the API
support *all* of the functions required by Mailets and a Mailet
container. This means for example that amongst other smaller stuff
some of the service interfaces for repositories need to be sorted and
refactored into the API

2/ Another thing I'd like to do would be to sort out IP based v
hosting and nameing convetion v hosting. Effectively certain
per-instance things, like the local repository, become per-vhost, and
local delivery gets to take the name of the repo as a param.

?
d.

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

Danny Angus wrote:
10/20/06, Stefano Bagnara <apache (AT) bago (DOT) orgwrote:
>Slightly more than a month ago I wrote a roadmap, here is an update for
>people that has not time for a day to day oversight.

Thanks Stefano ;-)

Can we consider timetabling some other changes now that we've made
such good progress?

Well, I think important things are:
1) don't delay the next release cycle once we added the features we
planned (and currenlty the only missing big piece is handlerapi, imho)
2) don't break the storage compatibility and the config.xml
compatibility (I think we currenlty kept both compatibilities).

1/ thing I have been trying to get "on the table" for a couple of
years(!) now is a re-write of the mailet API. We need to make the API
support *all* of the functions required by Mailets and a Mailet
container. This means for example that amongst other smaller stuff
some of the service interfaces for repositories need to be sorted and
refactored into the API

Rewriting mailet apis is not a simple task and I think it does not
belong to a "short timed" release like the one we're trying to do. Maybe
the following one.

I think that mailet api changes will need much more efforts and thoughts
and I think we should better delay this to a point where currenct active
committers will have a better overall overview of what services mailets
needs and how to try to fix this.

Furthermore I think we should better wait to have a clean handlerapi
structure because we should try to find a common way to access some of
the services offered by the container from in-protocol handlers and from
mailets.

2/ Another thing I'd like to do would be to sort out IP based v
hosting and nameing convetion v hosting. Effectively certain
per-instance things, like the local repository, become per-vhost, and
local delivery gets to take the name of the repo as a param.

?
d.

I think that we already did the bigger steps to make this possible.
Now it should be easy to alter the services to have a better support for
virtualhosting.

Can you elaborate some concrete solution?

I don't understand the "nameing convetion v hosting" thing: SMTP and
PP3 servers do not receive informations on the name used to reach them,
but only the IP used.

I think that the solution I found out-there to provide easy
out-of-the-box v hosting support is to put "user@domain" into the
UsersRepository and change "LocalDelivery" (ToMultiRepository) to use
the full recipient instead of the recipient.getName() when retrieving
the mailbox.

In PP3 people would have to use "user@domain" as login and no more "user".

We should also add DomainList service from the UsersRepository so that
James would automatically know what are the local domains by looking the
domains used in the UsersRepository names.

This should be relatively easy to be implemented now that we isolated
most of the services in few clean interfaces.

If my memory is right the only missing piece for this scenario is to
enhance the "ToMultiRepository" to let it use some parameter to define
the repository name.

You can read more at the end of this comment:
#action_12322582

Imho the key is to split every "big task" in many small tasks because
everyone here fear major changes so we should analyze the "big goal"
(that's why I ask you the concrete goal) and find out if we can do this
with small steps.

Unfortunately there are things that cannot be splitted in small tasks
and we have to delay: I have full DSN support for James waiting since
almost 2 years to be included because it needs a lot of changes in the
core of james and I don't have enough will and time to explain why every
change is needed so I gave up including it.

Stefano

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

Stefano Bagnara schrieb:
Danny Angus wrote:
>10/20/06, Stefano Bagnara <apache (AT) bago (DOT) orgwrote:
Slightly more than a month ago I wrote a roadmap, here is an update for
people that has not time for a day to day oversight.
>>
>Thanks Stefano ;-)
>>
>Can we consider timetabling some other changes now that we've made
>such good progress?
>
Well, I think important things are:
1) don't delay the next release cycle once we added the features we
planned (and currenlty the only missing big piece is handlerapi, imho)
2) don't break the storage compatibility and the config.xml
compatibility (I think we currenlty kept both compatibilities).
>
>1/ thing I have been trying to get "on the table" for a couple of
>years(!) now is a re-write of the mailet API. We need to make the API
>support *all* of the functions required by Mailets and a Mailet
>container. This means for example that amongst other smaller stuff
>some of the service interfaces for repositories need to be sorted and
>refactored into the API
>
Rewriting mailet apis is not a simple task and I think it does not
belong to a "short timed" release like the one we're trying to do.
Maybe the following one.

I think that mailet api changes will need much more efforts and
thoughts and I think we should better delay this to a point where
currenct active committers will have a better overall overview of what
services mailets needs and how to try to fix this.

Furthermore I think we should better wait to have a clean handlerapi
structure because we should try to find a common way to access some of
the services offered by the container from in-protocol handlers and
from mailets.
+1

>
>2/ Another thing I'd like to do would be to sort out IP based v
>hosting and nameing convetion v hosting. Effectively certain
>per-instance things, like the local repository, become per-vhost, and
>local delivery gets to take the name of the repo as a param.
>>
>?
>d.
>
I think that we already did the bigger steps to make this possible.
Now it should be easy to alter the services to have a better support
for virtualhosting.

Can you elaborate some concrete solution?

I don't understand the "nameing convetion v hosting" thing: SMTP and
PP3 servers do not receive informations on the name used to reach
them, but only the IP used.

I think that the solution I found out-there to provide easy
out-of-the-box v hosting support is to put "user@domain" into the
UsersRepository and change "LocalDelivery" (ToMultiRepository) to use
the full recipient instead of the recipient.getName() when retrieving
the mailbox.

In PP3 people would have to use "user@domain" as login and no more
"user".
Thats exactly what i whould like to see as next steps The path of the
mailboxes should also switch then to : /var/mail/domain/user
The enabling/disabling should be configurable to allow backwards
compatiblity. Disabled by default

We should also add DomainList service from the UsersRepository so that
James would automatically know what are the local domains by looking
the domains used in the UsersRepository names.

+1

This should be relatively easy to be implemented now that we isolated
most of the services in few clean interfaces.

If my memory is right the only missing piece for this scenario is to
enhance the "ToMultiRepository" to let it use some parameter to define
the repository name.

The my comment above
You can read more at the end of this comment:
#action_12322582
--
Imho the key is to split every "big task" in many small tasks because
everyone here fear major changes so we should analyze the "big goal"
(that's why I ask you the concrete goal) and find out if we can do
this with small steps.
+1
--
Unfortunately there are things that cannot be splitted in small tasks
and we have to delay: I have full DSN support for James waiting since
almost 2 years to be included because it needs a lot of changes in the
core of james and I don't have enough will and time to explain why
every change is needed so I gave up including it.

Stefano

I think we should think about adding DSN for the next release which
break the compatiblity

bye
Norman

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

10/21/06, Stefano Bagnara <apache (AT) bago (DOT) orgwrote:
Can we consider timetabling some other changes now that we've made
such good progress?

Well, I think important things are:
1) don't delay the next release cycle once we added the features we
planned (and currenlty the only missing big piece is handlerapi, imho)

I think perhaps its time we moved to having a status file.

2) don't break the storage compatibility and the config.xml
compatibility (I think we currenlty kept both compatibilities).

Not sure why you're so keen on this as one of only two things. Yes
this is important to end users for ease of upgrade, but it isn't
sacred. Tools can be provided to migrate content and configuration if
necessary.

Rewriting mailet apis is not a simple task and I think it does not
belong to a "short timed" release like the one we're trying to do. Maybe
the following one.

Yeah I figured. Same as always ;-)

I think that mailet api changes will need much more efforts and thoughts
and I think we should better delay this to a point where currenct active
committers will have a better overall overview of what services mailets
needs and how to try to fix this.

Well "current active" commiters are not everyone, there are still some
of us "less active" people who know and understand the API, what it
can be used for, and how it should be written. and whats more we also
know and understand its weaknesses and flaws.This work needs to be
done, and has been needed for a long time. It will have little effect
on James's mailets.

Furthermore I think we should better wait to have a clean handlerapi
structure because we should try to find a common way to access some of
the services offered by the container from in-protocol handlers and from
mailets.

Not sure I agree, unless the handlerapi is being proposed for adding to mailet.
Theres no reason why the same services shouldn't be available in
different ways, its just a case of wrapping and decorating things.

I don't understand the "nameing convetion v hosting" thing: SMTP and
PP3 servers do not receive informations on the name used to reach them,
but only the IP used.

Yeah, correct. But people keep proposing that PP3 vhosting involve
people logging in with user@domain or some other work-around. this
*is* name based vhosting for pop3, the name is derived from the
log-in, you propose such a solution youself below. The other option is
to bind certain domains to certain IP addresses in the same James
instance.

I think that the solution I found out-there to provide easy
out-of-the-box v hosting support is to put "user@domain" into the
UsersRepository and change "LocalDelivery" (ToMultiRepository) to use
the full recipient instead of the recipient.getName() when retrieving
the mailbox.

That locks you into using one repository, I'm proposing that a
different repository can be used per "host" and that hosts can be
distinguished by either IP address or naming convention.

In PP3 people would have to use "user@domain" as login and no more "user".

Unless you used IP based Vhosting.

We should also add DomainList service from the UsersRepository so that
James would automatically know what are the local domains by looking the
domains used in the UsersRepository names.

Yeah, not 100% sure it would work for all scenarios, but it would be
worth the effort to do the analysis.

This should be relatively easy to be implemented now that we isolated
most of the services in few clean interfaces.

If my memory is right the only missing piece for this scenario is to
enhance the "ToMultiRepository" to let it use some parameter to define
the repository name.

Well thats true to some extent. but only if you accept that your
proposal is enough and as far as we'd want to go.

You can read more at the end of this comment:
#action_12322582

Problem accessing this just now :-(

Imho the key is to split every "big task" in many small tasks because
everyone here fear major changes so we should analyze the "big goal"
(that's why I ask you the concrete goal) and find out if we can do this
with small steps.

Yeah K, but it is necessary to catalogue our goals and do some planning.
we get into a rut of making small changes all the time with
no longer term plan.

--
Unfortunately there are things that cannot be splitted in small tasks
and we have to delay: I have full DSN support for James waiting since
almost 2 years to be included because it needs a lot of changes in the
core of james and I don't have enough will and time to explain why every
change is needed so I gave up including it.

We'll perhaps the time is right for us to start to perpare some proper
plans. and a proper timetable of releases.

d.

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

10/21/06, Norman Maurer <nm (AT) byteaction (DOT) dewrote:

In PP3 people would have to use "user@domain" as login and no more
"user".
Thats exactly what i whould like to see as next steps The path of the
mailboxes should also switch then to : /var/mail/domain/user
The enabling/disabling should be configurable to allow backwards
compatiblity. Disabled by default

Yeah, no disagreement about the paths, I just don't think it needs to
be tied to a specific naming convention for user log-ins.

I think we should think about adding DSN for the next release which
break the compatiblity

I think we should be looking at our planning process.

d.

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

Danny Angus wrote:
10/21/06, Stefano Bagnara <apache (AT) bago (DOT) orgwrote:
>Can we consider timetabling some other changes now that we've made
>such good progress?
>>
>Well, I think important things are:
>1) don't delay the next release cycle once we added the features we
>planned (and currenlty the only missing big piece is handlerapi, imho)

I think perhaps its time we moved to having a status file.

I'm happy enough with what JIRA roadmaps give us.
I don't know what exactly you mean with "status file" but I would not
like having more pieces to mantain. It is already boring enough to
manually update the changelog in our website at each release.

>2) don't break the storage compatibility and the config.xml
>compatibility (I think we currenlty kept both compatibilities).

Not sure why you're so keen on this as one of only two things. Yes
this is important to end users for ease of upgrade, but it isn't
sacred. Tools can be provided to migrate content and configuration if
necessary.

I've added this point because Noel and Vincenzo brought this as an
important point in the 2.4 roadmap discussion.
I personally don't care of config.xml compatibility: I was just
reporting what I understood was important (and feasible) to the PMC.

>Rewriting mailet apis is not a simple task and I think it does not
>belong to a "short timed" release like the one we're trying to do. Maybe
>the following one.

Yeah I figured. Same as always ;-)

>I think that mailet api changes will need much more efforts and thoughts
>and I think we should better delay this to a point where currenct active
>committers will have a better overall overview of what services mailets
>needs and how to try to fix this.

Well "current active" commiters are not everyone, there are still some
of us "less active" people who know and understand the API, what it
can be used for, and how it should be written. and whats more we also
know and understand its weaknesses and flaws.This work needs to be
done, and has been needed for a long time. It will have little effect
on James's mailets.

Well, don't take me wrong: I never intended to stop you from working on
this. If you have the time and will to do that then feel free to start
some proposal (either with code or discussion as you prefer).
I just would avoid starting discussions on things that have no
"champion" to do the concrete work at the end because I'm running short
in time and I prefer to concentrate on things that I already thought in
past. I admit I didn't think to mailet apis too much but I did this in
past and I wrote something (also in the mailet-api list) and it seems we
(all) have really different ideas about the next mailet apis, so I
decided to avoid the topic to concentrate on something simpler.

Maybe someone receiving less vetoes to proposals ;-) will be more likely
to do this step.

>Furthermore I think we should better wait to have a clean handlerapi
>structure because we should try to find a common way to access some of
>the services offered by the container from in-protocol handlers and from
>mailets.

Not sure I agree, unless the handlerapi is being proposed for adding to
mailet.
Theres no reason why the same services shouldn't be available in
different ways, its just a case of wrapping and decorating things.

As I said we probably don't agree on the future of the mailet apis ;-)
Beside joking, I believe that now that we are here we should wait to
find a good solution to services to be provided to "handlers plugins"
and maybe the same patterns could be used in the next mailet. I simply
thought at this roadmap because I thought it was convenient:
unfortunately the time is really much less than what I would like to do
on James.
Btw you shouldn't fear me: I rerely use vetoes and always prefer an
average/partial solution to no solution. And I would be really happy to
see some new concrete effort by "less active" committers!

>I don't understand the "nameing convetion v hosting" thing: SMTP and
>PP3 servers do not receive informations on the name used to reach them,
>but only the IP used.

Yeah, correct. But people keep proposing that PP3 vhosting involve
people logging in with user@domain or some other work-around. this
*is* name based vhosting for pop3, the name is derived from the
log-in, you propose such a solution youself below. The other option is
to bind certain domains to certain IP addresses in the same James
instance.

, so if we let pop3 users to have the "@domain" and we add to the
pop3server a configuration for a default domain to be used when no
domain is passed would solve both issues, right?
Now if we want to bind the pop3server to multiple IPs we have to declare
multiple <pop3serverblocks anyway: is this right?

>I think that the solution I found out-there to provide easy
>out-of-the-box v hosting support is to put "user@domain" into the
>UsersRepository and change "LocalDelivery" (ToMultiRepository) to use
>the full recipient instead of the recipient.getName() when retrieving
>the mailbox.

That locks you into using one repository, I'm proposing that a
different repository can be used per "host" and that hosts can be
distinguished by either IP address or naming convention.

Well, ToMultiRepository try first to retrieve the user inbox via
MailServer.getUserInbox method. IIRC it shouldn't be so hard to isolate
also this method in the new services we added lately. I'll try to
remember this the next time I'll review the code about this issue.

>In PP3 people would have to use "user@domain" as login and no more
>"user".

Unless you used IP based Vhosting.

Right.

>We should also add DomainList service from the UsersRepository so that
>James would automatically know what are the local domains by looking the
>domains used in the UsersRepository names.

Yeah, not 100% sure it would work for all scenarios, but it would be
worth the effort to do the analysis.

>This should be relatively easy to be implemented now that we isolated
>most of the services in few clean interfaces.
>>
>If my memory is right the only missing piece for this scenario is to
>enhance the "ToMultiRepository" to let it use some parameter to define
>the repository name.

Well thats true to some extent. but only if you accept that your
proposal is enough and as far as we'd want to go.

I accept this ;-)

>You can read more at the end of this comment:
>#action_12322582

Problem accessing this just now :-(

Now it should work again.

>Imho the key is to split every "big task" in many small tasks because
>everyone here fear major changes so we should analyze the "big goal"
>(that's why I ask you the concrete goal) and find out if we can do this
>with small steps.

Yeah K, but it is necessary to catalogue our goals and do some planning.
we get into a rut of making small changes all the time with
no longer term plan.

Well, as you can see the goals I proposed (and that at least Norman
agreed) was listed on that topic and we have took them seriously enough.
I think that I can't do anything more than proposing a list, finding a
"working crew" sharing the same goals and get things done ;-).
I tried for more than an year to do some bigger planning and bigger
changes but I failed. Even small changes have been vetoed, so I won't
loose much more time on big goals if there is a chance to be vetoed at
the first step. I can leave this task to someone with more social talent
than me with this.

>Unfortunately there are things that cannot be splitted in small tasks
>and we have to delay: I have full DSN support for James waiting since
>almost 2 years to be included because it needs a lot of changes in the
>core of james and I don't have enough will and time to explain why every
>change is needed so I gave up including it.

We'll perhaps the time is right for us to start to perpare some proper
plans. and a proper timetable of releases.

Feel free to do some proposal, but remember that in not paid open source
it is hard to write timetable for others.
I think that Norman and I did exactly a proper plan and almost a proper
timetable because we put on the table tasks that we was willing to do.
I would be happy to start discussing a bigger/better roadmap: anyone
should start writing what they will be willing to work on and when. THen
we can see how to solve the puzzle (and what can be part of James and
what not).

I personally don't have a fixed roadmap: it depends on my mood and
sometimes on what features my clients are willing to pay me for ;-) but
I always try to keep trunk consistent and to commit things only when I
know I can finish it.

Stefano

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

Hi Stefano,

Thanks for your detailed reply, I hope my comments below will reassure
you that I'm not proposing anything radical, just a slightly more
visible planning process, and some small refactorings.
I also hope that we're beginning to reach a common understanding of
what James project is lacking and how to take the next step from
having tactical (I don't want to pretend you are stupid, but I know
that English is not everyone's best language, tactical means short
term) decision making towards strategic (means long term).

10/24/06, Stefano Bagnara <apache (AT) bago (DOT) orgwrote:

I'm happy enough with what JIRA roadmaps give us.
I don't know what exactly you mean with "status file" but I would not
like having more pieces to mantain.

the STATUS file is a mechanism used by Apache projects to record what
work is planned and who is doing it.
It allows the project cope with both a rapid cycle of defect fixes and
minor enhancements, and with a longer cycle of major refactorings.

It is already boring enough to
manually update the changelog in our website at each release.

Yes that is a painful task, but this is not the same thing, it isn't
about what has changed but about everyone being able to record what
they are working on and what state it is in.
It can make planning releases much easier.

I've added this point because Noel and Vincenzo brought this as an
important point in the 2.4 roadmap discussion.
I personally don't care of config.xml compatibility: I was just
reporting what I understood was important (and feasible) to the PMC.

Fair enough, in that case I direct my point to Noel and Vincezo ;-)

Well, don't take me wrong: I never intended to stop you from working on
this. If you have the time and will to do that then feel free to start
some proposal (either with code or discussion as you prefer).
I just would avoid starting discussions on things that have no
"champion" to do the concrete work at the end because I'm running short
in time and I prefer to concentrate on things that I already thought in
past.

no! I wasn't suggesting that anyone other than me do this, and yes
I'll propose it in more detail first.
The problem is that it results in a major release (because the API
changes) and this can mess up the schedule of defect and minor
enhancement releases.

I admit I didn't think to mailet apis too much but I did this in
past and I wrote something (also in the mailet-api list) and it seems we
(all) have really different ideas about the next mailet apis, so I
decided to avoid the topic to concentrate on something simpler.

K, I agree that we have different ideas, I would hope to show that
mine is just a normalising refactoring and doesn't conflict with any
API enhancements others may have in mind.

Maybe someone receiving less vetoes to proposals ;-) will be more likely
to do this step.

Ha! :-D :-D

As I said we probably don't agree on the future of the mailet apis ;-)
Beside joking, I believe that now that we are here we should wait to
find a good solution to services to be provided to "handlers plugins"
and maybe the same patterns could be used in the next mailet.

+1 I agree, I'm not suggesting that the mailet changes be released
quickly, just that work could start soon.

I simply
thought at this roadmap because I thought it was convenient:
unfortunately the time is really much less than what I would like to do
on James.

I know, I'm just using this opportunity to put my cards on the table again.

Btw you shouldn't fear me: I rerely use vetoes and always prefer an
average/partial solution to no solution. And I would be really happy to
see some new concrete effort by "less active" committers!

I've been very busy for a long time now, but I'm finding more
opportunities now, and I'm keen to re-start where I left off, which
was looking at vhosting and a mailet API SDK (which requires some
small chages to the API as an enabler).

, so if we let pop3 users to have the "@domain" and we add to the
pop3server a configuration for a default domain to be used when no
domain is passed would solve both issues, right?

Right.

Now if we want to bind the pop3server to multiple IPs we have to declare
multiple <pop3serverblocks anyway: is this right?

Right.
All we need to do is to allow the <pop3serverblocks to take the
repository as a config param. and to let the local delivery mailet do
the same thing.

Well, ToMultiRepository try first to retrieve the user inbox via
MailServer.getUserInbox method. IIRC it shouldn't be so hard to isolate
also this method in the new services we added lately.

Agree.

I'll try to
remember this the next time I'll review the code about this issue.

Thanks

Well thats true to some extent. but only if you accept that your
proposal is enough and as far as we'd want to go.

I accept this ;-)

:-D :-D.

>
>You can read more at the end of this comment:
>#action_12322582
>
Problem accessing this just now :-(

Now it should work again.

I agree with that. Looks good.

Well, as you can see the goals I proposed (and that at least Norman
agreed) was listed on that topic and we have took them seriously enough.
I think that I can't do anything more than proposing a list, finding a
"working crew" sharing the same goals and get things done ;-).

I'm not disagreeing with this at all, just saying that I think we
should consider recording what we're doing, and what we're planning at
a high level in the status file, so that we have one single list we
can use to plan releases.
This is about unblocking the big changes which we know we want but
can't agree when or how to do them.

I tried for more than an year to do some bigger planning and bigger
changes but I failed.

I know, and I think that the problem for some people was that the
proposals involved a lot of change, and the discussions went into a
lot of detail and moved very quickly.
I'm suggesting that one way to get these things agreed may be to
record the proposals (on the wiki?) discuss them here and revise them
then vote them into the status file where they are "officially
recorded", rather than record discuss and vote all in one mail thread.
IIRC Many of your high level proposals were rejected because whilst
people agreed with the high level, and many aspects of the detail it
was only one or two aspects of the detail which put people off.
Separating the high level proposal from the detailed design of its
implementation might allow more things to be agreed in principle, and
then we can delay arguing over details until we are ready to implement
the details, by which time we may be clearer about what is required
and what is achievable.
Do you see what I mean?

Even small changes have been vetoed, so I won't
loose much more time on big goals if there is a chance to be vetoed at
the first step. I can leave this task to someone with more social talent
than me with this.

(see above)
I hope that this is one thing that I *can* contribute ;-) not only do
I have years of experience of annoying people @apache, but getting
groups to reach consensus based decisions is also one of the skills I
use in my day job.

Feel free to do some proposal, but remember that in not paid open source
it is hard to write timetable for others.

I think I'm even more aware of this than you are, it is exactly why I
can't spend the time on James that I used to.

I think that Norman and I did exactly a proper plan and almost a proper
timetable because we put on the table tasks that we was willing to do.

Right, and thats the right thing to do. If everyone adds their own
thing to a list (the status file?) we can see what everyone is capable
of achieving, and outline the contents of planned releases without
having to comit to dates.
Releases need to be roughly planned for major and minor cycles to
prevent major changes from blocking defect fixes.

I would be happy to start discussing a bigger/better roadmap: anyone
should start writing what they will be willing to work on and when. THen
we can see how to solve the puzzle (and what can be part of James and
what not).

I think I will propose the use of the status file, and we can see what
we think once we've tried it, unless it gets shot down by the veto
brigade ;-).

I personally don't have a fixed roadmap: it depends on my mood and
sometimes on what features my clients are willing to pay me for ;-) but
I always try to keep trunk consistent and to commit things only when I
know I can finish it.

Thats the right approach, and (if you don't mind me saying so) one of
several reasons that your contributions have been such a sucess, which
in turn has encouraged others to become more involved.

d.

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

Hi Danny,

I extracted the status file related sentences from the previous message.
I think that the "in-progress" issues in JIRA already have the
informations you would like to add to the status file:

In fact I would prefer to use JIRA for tasks, for roadmaps, and for
tracking.

Furthermore I also use the "Assignment" also for issues I'm not
currently working on, but I think I should be contacted before anyone
else approach the same problem:

You can see that I have DSN support, memory efficient retrieval, remote
delivery service and more: I worked on all of this, I probably have
almost working code for each one, but I'm not ready to discuss about all
the complications of committing them to trunk.

If we can agree on a standard workflow/usage of JIRA I would prefer it
over a status file to be committed in svn. I update JIRA when I
have no other access than http and I can't commit so I use that spare
time to update/reorganize JIRA.

I would be happy to be able to have a more clear roadmap about the next
release and I could update the current trunk roadmap:

to remove some of the "UNRESLVED" issues that we already know won't be
part of the next release.
E.g: there is no effort on the IPV6 side, so we could remove the ipv6
issues from that roadmap.

I often asked people to review that list and to say what they think
should be removed, what they think is a must, what they think is an option.

Briefly: I'm +1 to increase the usage of JIRA also for our
roadmap/status tracking. -0 on the introduction of a status file in svn.

Stefano

Danny Angus wrote:
Stefano Bagnara wrote:
>I'm happy enough with what JIRA roadmaps give us.
>I don't know what exactly you mean with "status file" but I would not
>like having more pieces to mantain.

the STATUS file is a mechanism used by Apache projects to record what
work is planned and who is doing it.
It allows the project cope with both a rapid cycle of defect fixes and
minor enhancements, and with a longer cycle of major refactorings.

>It is already boring enough to
>manually update the changelog in our website at each release.

Yes that is a painful task, but this is not the same thing, it isn't
about what has changed but about everyone being able to record what
they are working on and what state it is in.
It can make planning releases much easier.
[]
>I think that Norman and I did exactly a proper plan and almost a proper
>timetable because we put on the table tasks that we was willing to do.

Right, and thats the right thing to do. If everyone adds their own
thing to a list (the status file?) we can see what everyone is capable
of achieving, and outline the contents of planned releases without
having to comit to dates.
Releases need to be roughly planned for major and minor cycles to
prevent major changes from blocking defect fixes.

>I would be happy to start discussing a bigger/better roadmap: anyone
>should start writing what they will be willing to work on and when. THen
>we can see how to solve the puzzle (and what can be part of James and
>what not).

I think I will propose the use of the status file, and we can see what
we think once we've tried it, unless it gets shot down by the veto
brigade ;-).

>I personally don't have a fixed roadmap: it depends on my mood and
>sometimes on what features my clients are willing to pay me for ;-) but
>I always try to keep trunk consistent and to commit things only when I
>know I can finish it.

Thats the right approach, and (if you don't mind me saying so) one of
several reasons that your contributions have been such a sucess, which
in turn has encouraged others to become more involved.

d.

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

I extracted things related to VHosting from the roadmap thread, and my
only reply is at the end of this message.

Danny Angus wrote:
I've been very busy for a long time now, but I'm finding more
opportunities now, and I'm keen to re-start where I left off, which
was looking at vhosting and a mailet API SDK (which requires some
small chages to the API as an enabler).

>, so if we let pop3 users to have the "@domain" and we add to the
>pop3server a configuration for a default domain to be used when no
>domain is passed would solve both issues, right?

Right.

>Now if we want to bind the pop3server to multiple IPs we have to declare
>multiple <pop3serverblocks anyway: is this right?

Right.
All we need to do is to allow the <pop3serverblocks to take the
repository as a config param. and to let the local delivery mailet do
the same thing.

>Well, ToMultiRepository try first to retrieve the user inbox via
>MailServer.getUserInbox method. IIRC it shouldn't be so hard to isolate
>also this method in the new services we added lately.

Agree.

>I'll try to
>remember this the next time I'll review the code about this issue.

Thanks

>Well thats true to some extent. but only if you accept that your
>proposal is enough and as far as we'd want to go.
>>
>I accept this ;-)

:-D :-D.

>>You can read more at the end of this comment:
>>#action_12322582
>>
>Problem accessing this just now :-(
>>
>Now it should work again.

I agree with that. Looks good.

>Even small changes have been vetoed, so I won't
>loose much more time on big goals if there is a chance to be vetoed at
>the first step. I can leave this task to someone with more social talent
>than me with this.

(see above)
I hope that this is one thing that I *can* contribute ;-) not only do
I have years of experience of annoying people @apache, but getting
groups to reach consensus based decisions is also one of the skills I
use in my day job.

I would ask you one important thing: as you talk english better than me
and you know Noel much more than me try to discuss the vhosting issue
with Noel and let's see if both of you can at least agree on a common
roadmap on this issue. you have this we can then see if this
roadmap is acceptable to me and Norman (as we are the one that put their
hands in the code until now on this issue).

I just have too much problems understanding and accepting Noel replies
to all of my message, so if you feel you can contribute on this I would
be happy.

Stefano

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

Danny Angus wrote:
Hi Stefano,

Thanks for your detailed reply, I hope my comments below will reassure
you that I'm not proposing anything radical, just a slightly more
visible planning process, and some small refactorings.
I also hope that we're beginning to reach a common understanding of
what James project is lacking and how to take the next step from
having tactical (I don't want to pretend you are stupid, but I know
that English is not everyone's best language, tactical means short
term) decision making towards strategic (means long term).

Thank you for remembering this!
I splitted this reply in 4 because we have too much things in the same
thread.

For virtual hosting and status file I "branched" the topic on
server-dev, while for maielt apis discussion I branched to the
mailet-api list!

10/24/06, Stefano Bagnara <apache (AT) bago (DOT) orgwrote:
>I tried for more than an year to do some bigger planning and bigger
>changes but I failed.

I know, and I think that the problem for some people was that the
proposals involved a lot of change, and the discussions went into a
lot of detail and moved very quickly.
I'm suggesting that one way to get these things agreed may be to
record the proposals (on the wiki?) discuss them here and revise them
then vote them into the status file where they are "officially
recorded", rather than record discuss and vote all in one mail thread.
IIRC Many of your high level proposals were rejected because whilst
people agreed with the high level, and many aspects of the detail it
was only one or two aspects of the detail which put people off.
Separating the high level proposal from the detailed design of its
implementation might allow more things to be agreed in principle, and
then we can delay arguing over details until we are ready to implement
the details, by which time we may be clearer about what is required
and what is achievable.
Do you see what I mean?

I'm not a fan of WIKIs, and the fact that there are already a lot of
outdated proposals there make me fear.

Btw I can live with WIKIs too, so if you think using wiki give us a
better workflow we can give it a try (as a sidenote I would prefer
confluence over the current wiki).

About Wiki I saw that felix, directory and geronimo projects started
using Confluence also for their website creation: they use confluence to
edit the structure and then export it statically to update the official
website. I think that if we want to "re-introduce" wiki in the james
project it would be cool to solve the "website updates" problems.

If I understood it there is also a maven2 plugin to include in the
website generation pages retrieved from confluence. Unfortunately there
is no such facility for MoinMoin.

>I personally don't have a fixed roadmap: it depends on my mood and
>sometimes on what features my clients are willing to pay me for ;-) but
>I always try to keep trunk consistent and to commit things only when I
>know I can finish it.

Thats the right approach, and (if you don't mind me saying so) one of
several reasons that your contributions have been such a sucess, which
in turn has encouraged others to become more involved.

d.

Feel free to say this as many times as you can ;-)

Stefano

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

Danny Angus wrote:
10/24/06, Stefano Bagnara <apache (AT) bago (DOT) orgwrote:
>
>I've added this point because Noel and Vincenzo brought this as an
>important point in the 2.4 roadmap discussion.
>I personally don't care of config.xml compatibility: I was just
>reporting what I understood was important (and feasible) to the PMC.
>
Fair enough, in that case I direct my point to Noel and Vincezo ;-)
--
We just stressed the fact that life must be kept as much as possible
easy for users when upgrading to new release, otherwise they may stay
behind. Regarding configurations, this goal can be achieved either
keeping as much as possible backward compatibility for existing
features, either providing (safe and thoroughly tested) conversion
tools. But we have to be aware that slowly adding small configuration
incompatibilities can sum up to require complex conversion tools, that
nobody would develop and would become a bottleneck when releasing a new
version.

Source Communities can create better and smarter software than
Commercial Companies, but the latter normally care more of existing
"dumb" users: we should always try to reach a good compromise ;-) .

Vincenzo

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

Vincenzo Gianferrari Pini wrote:
Danny Angus wrote:
>10/24/06, Stefano Bagnara <apache (AT) bago (DOT) orgwrote:
>>
I've added this point because Noel and Vincenzo brought this as an
important point in the 2.4 roadmap discussion.
I personally don't care of config.xml compatibility: I was just
reporting what I understood was important (and feasible) to the PMC.
>>
>Fair enough, in that case I direct my point to Noel and Vincezo ;-)
>
We just stressed the fact that life must be kept as much as possible
easy for users when upgrading to new release, otherwise they may stay
behind. Regarding configurations, this goal can be achieved either
keeping as much as possible backward compatibility for existing
features, either providing (safe and thoroughly tested) conversion
tools. But we have to be aware that slowly adding small configuration
incompatibilities can sum up to require complex conversion tools, that
nobody would develop and would become a bottleneck when releasing a new
version.

Source Communities can create better and smarter software than
Commercial Companies, but the latter normally care more of existing
"dumb" users: we should always try to reach a good compromise ;-) .

Vincenzo

Well, I won't write conversion tools, so I preferred to remember your
ideas/suggestions when I thought at the proposed roadmap.

I personally prefer a "new feature that break backward compatibility"
than "no new feature" but we have a lot of stuff that can be done
without breaking backward compatibility.

I simply pointed out that what Noel and Vincenzo proposed to release was
already breaking assembly.xml compatiblity so only could try to achieve
config.xml compatibility (and storage compatibility) and at least Norman
and I always think at this issue when we implement/test new features.

I'm sure most of you already know this, but I rewrite it again for
Danny: my idea was that storage compatibility would have been enough,
with no conversion tools (that's what we did with 2.2.0 to 2.3.0), but
we are a community and I'm not as fanatic as someone could think.

Stefano

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

Danny Angus wrote:
Right, and thats the right thing to do. If everyone adds their own
thing to a list (the status file?) we can see what everyone is capable
of achieving, and outline the contents of planned releases without
having to comit to dates.
Releases need to be roughly planned for major and minor cycles to
prevent major changes from blocking defect fixes.

I just saw that you didn't partecipate to this thread 1 month ago. You
should read it and maybe add your comments:
%

I say this because I see you're asking for roadmaps, for issue list, for
discussions about that. I think that if you read the whole thread you
will notice that I tried to do this already 1 month ago.

We saw 2 different approaches, they was not one against the other but
simply 2 road maps. You can find many messages from me with no
replies It was clear that I, Norman and Bernd shared a common goal,
so we simply started working on this one.

Stefano

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

Hi Danny,

something to say

Danny Angus schrieb:
Hi Stefano,

Thanks for your detailed reply, I hope my comments below will reassure
you that I'm not proposing anything radical, just a slightly more
visible planning process, and some small refactorings.
I also hope that we're beginning to reach a common understanding of
what James project is lacking and how to take the next step from
having tactical (I don't want to pretend you are stupid, but I know
that English is not everyone's best language, tactical means short
term) decision making towards strategic (means long term).

10/24/06, Stefano Bagnara <apache (AT) bago (DOT) orgwrote:
>
>
>I'm happy enough with what JIRA roadmaps give us.
>I don't know what exactly you mean with "status file" but I would not
>like having more pieces to mantain.
>
the STATUS file is a mechanism used by Apache projects to record what
work is planned and who is doing it.
It allows the project cope with both a rapid cycle of defect fixes and
minor enhancements, and with a longer cycle of major refactorings.
We can test it but i aspect not much of it Anyway i will be happy if
im wrong.

>
>It is already boring enough to
>manually update the changelog in our website at each release.
>
Yes that is a painful task, but this is not the same thing, it isn't
about what has changed but about everyone being able to record what
they are working on and what state it is in.
It can make planning releases much easier.
>
>I've added this point because Noel and Vincenzo brought this as an
>important point in the 2.4 roadmap discussion.
>I personally don't care of config.xml compatibility: I was just
>reporting what I understood was important (and feasible) to the PMC.
>
Fair enough, in that case I direct my point to Noel and Vincezo ;-)
>
>Well, don't take me wrong: I never intended to stop you from working on
>this. If you have the time and will to do that then feel free to start
>some proposal (either with code or discussion as you prefer).
>I just would avoid starting discussions on things that have no
>"champion" to do the concrete work at the end because I'm running short
>in time and I prefer to concentrate on things that I already thought in
>past.
>
no! I wasn't suggesting that anyone other than me do this, and yes
I'll propose it in more detail first.
The problem is that it results in a major release (because the API
changes) and this can mess up the schedule of defect and minor
enhancement releases.
I lookin forward to this Please go ahead.
>
>I admit I didn't think to mailet apis too much but I did this in
>past and I wrote something (also in the mailet-api list) and it seems we
>(all) have really different ideas about the next mailet apis, so I
>decided to avoid the topic to concentrate on something simpler.
>
K, I agree that we have different ideas, I would hope to show that
mine is just a normalising refactoring and doesn't conflict with any
API enhancements others may have in mind.
We should just find a good solution to lookup Services without bundle
the mailets to tight to james. If i understand it right then the mailets
should work without james


>
>
>>
>Maybe someone receiving less vetoes to proposals ;-) will be more likely
>to do this step.
>
Ha! :-D :-D
Maybe i should try I'm everyones most loved guy :-P

>
>
>
>As I said we probably don't agree on the future of the mailet apis ;-)
>Beside joking, I believe that now that we are here we should wait to
>find a good solution to services to be provided to "handlers plugins"
>and maybe the same patterns could be used in the next mailet.
>
+1 I agree, I'm not suggesting that the mailet changes be released
quickly, just that work could start soon.
>
>I simply
>thought at this roadmap because I thought it was convenient:
>unfortunately the time is really much less than what I would like to do
>on James.
>
I know, I'm just using this opportunity to put my cards on the table
again.
>
>Btw you shouldn't fear me: I rerely use vetoes and always prefer an
>average/partial solution to no solution. And I would be really happy to
>see some new concrete effort by "less active" committers!
>
I've been very busy for a long time now, but I'm finding more
opportunities now, and I'm keen to re-start where I left off, which
was looking at vhosting and a mailet API SDK (which requires some
small chages to the API as an enabler).
Im happy to hear.
>
>
>, so if we let pop3 users to have the "@domain" and we add to the
>pop3server a configuration for a default domain to be used when no
>domain is passed would solve both issues, right?
>
Right.
I think thats a very good solution and should also fix noels -1 .
>
>
>Now if we want to bind the pop3server to multiple IPs we have to declare
>multiple <pop3serverblocks anyway: is this right?
>
Right.
All we need to do is to allow the <pop3serverblocks to take the
repository as a config param. and to let the local delivery mailet do
the same thing.
I think thats cool but i don't see so many user cases. I prefer the
"normal" vhosting like vpopmail etc do it

>
>
>Well, ToMultiRepository try first to retrieve the user inbox via
>MailServer.getUserInbox method. IIRC it shouldn't be so hard to isolate
>also this method in the new services we added lately.
>
Agree.
+1 for isolating
>
>
>I'll try to
>remember this the next time I'll review the code about this issue.
>
Thanks
>
>
>
>Well thats true to some extent. but only if you accept that your
>proposal is enough and as far as we'd want to go.
>>
>I accept this ;-)
>
:-D :-D.
>
>>
>>You can read more at the end of this comment:
>>#action_12322582
>>
>Problem accessing this just now :-(
>>
>Now it should work again.
>
I agree with that. Looks good.

+1
>>
>Well, as you can see the goals I proposed (and that at least Norman
>agreed) was listed on that topic and we have took them seriously enough.
>I think that I can't do anything more than proposing a list, finding a
>"working crew" sharing the same goals and get things done ;-).
>
I'm not disagreeing with this at all, just saying that I think we
should consider recording what we're doing, and what we're planning at
a high level in the status file, so that we have one single list we
can use to plan releases.
This is about unblocking the big changes which we know we want but
can't agree when or how to do them.
>
>I tried for more than an year to do some bigger planning and bigger
>changes but I failed.
>
I know, and I think that the problem for some people was that the
proposals involved a lot of change, and the discussions went into a
lot of detail and moved very quickly.
I'm suggesting that one way to get these things agreed may be to
record the proposals (on the wiki?) discuss them here and revise them
then vote them into the status file where they are "officially
recorded", rather than record discuss and vote all in one mail thread.
IIRC Many of your high level proposals were rejected because whilst
people agreed with the high level, and many aspects of the detail it
was only one or two aspects of the detail which put people off.
Separating the high level proposal from the detailed design of its
implementation might allow more things to be agreed in principle, and
then we can delay arguing over details until we are ready to implement
the details, by which time we may be clearer about what is required
and what is achievable.
Do you see what I mean?
I think the most problems of people are that they fear to "break"
james But why we should fear with new junit tests :-P
>
>
>Even small changes have been vetoed, so I won't
>loose much more time on big goals if there is a chance to be vetoed at
>the first step. I can leave this task to someone with more social talent
>than me with this.
>
(see above)
I hope that this is one thing that I *can* contribute ;-) not only do
I have years of experience of annoying people @apache, but getting
groups to reach consensus based decisions is also one of the skills I
use in my day job.
>
>
>Feel free to do some proposal, but remember that in not paid open source
>it is hard to write timetable for others.
>
I think I'm even more aware of this than you are, it is exactly why I
can't spend the time on James that I used to.
>
>I think that Norman and I did exactly a proper plan and almost a proper
>timetable because we put on the table tasks that we was willing to do.
>
Right, and thats the right thing to do. If everyone adds their own
thing to a list (the status file?) we can see what everyone is capable
of achieving, and outline the contents of planned releases without
having to comit to dates.
Releases need to be roughly planned for major and minor cycles to
prevent major changes from blocking defect fixes.
:-D :-D
>
>I would be happy to start discussing a bigger/better roadmap: anyone
>should start writing what they will be willing to work on and when. THen
>we can see how to solve the puzzle (and what can be part of James and
>what not).
>
I think I will propose the use of the status file, and we can see what
we think once we've tried it, unless it gets shot down by the veto
brigade ;-).
Go ahead
>
>
>I personally don't have a fixed roadmap: it depends on my mood and
>sometimes on what features my clients are willing to pay me for ;-) but
>I always try to keep trunk consistent and to commit things only when I
>know I can finish it.
>
Thats the right approach, and (if you don't mind me saying so) one of
several reasons that your contributions have been such a sucess, which
in turn has encouraged others to become more involved.

d.

Agree

bye
Norman

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

Vincenzo Gianferrari Pini schrieb:
Danny Angus wrote:
>10/24/06, Stefano Bagnara <apache (AT) bago (DOT) orgwrote:
>>
I've added this point because Noel and Vincenzo brought this as an
important point in the 2.4 roadmap discussion.
I personally don't care of config.xml compatibility: I was just
reporting what I understood was important (and feasible) to the PMC.
>>
>Fair enough, in that case I direct my point to Noel and Vincezo ;-)
>>
>>
We just stressed the fact that life must be kept as much as possible
easy for users when upgrading to new release, otherwise they may stay
behind. Regarding configurations, this goal can be achieved either
keeping as much as possible backward compatibility for existing
features, either providing (safe and thoroughly tested) conversion
tools. But we have to be aware that slowly adding small configuration
incompatibilities can sum up to require complex conversion tools, that
nobody would develop and would become a bottleneck when releasing a
new version.

Source Communities can create better and smarter software than
Commercial Companies, but the latter normally care more of existing
"dumb" users: we should always try to reach a good compromise ;-) .

Vincenzo

Thats right but with no new features we will loose users and not get
new I think we just need to document what to change in config.xml. I
allready add an UPGRADING.txt to the 2.3 branch. If we add some new
feature which need things the get changed in config.xml we just should
document it in a UPGRADING.txt

bye
Norman

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

Norman Maurer wrote:
Vincenzo Gianferrari Pini schrieb:

>Danny Angus wrote:
>
10/24/06, Stefano Bagnara <apache (AT) bago (DOT) orgwrote:

I've added this point because Noel and Vincenzo brought this as an
important point in the 2.4 roadmap discussion.
I personally don't care of config.xml compatibility: I was just
reporting what I understood was important (and feasible) to the PMC.

Fair enough, in that case I direct my point to Noel and Vincezo ;-)


>We just stressed the fact that life must be kept as much as possible
>easy for users when upgrading to new release, otherwise they may stay
>behind. Regarding configurations, this goal can be achieved either
>keeping as much as possible backward compatibility for existing
>features, either providing (safe and thoroughly tested) conversion
>tools. But we have to be aware that slowly adding small configuration
>incompatibilities can sum up to require complex conversion tools, that
>nobody would develop and would become a bottleneck when releasing a
>new version.
>>
>Source Communities can create better and smarter software than
>Commercial Companies, but the latter normally care more of existing
>"dumb" users: we should always try to reach a good compromise ;-) .
>>
>Vincenzo
>
>
Thats right but with no new features we will loose users and not get
new I think we just need to document what to change in config.xml. I
allready add an UPGRADING.txt to the 2.3 branch. If we add some new
feature which need things the get changed in config.xml we just should
document it in a UPGRADING.txt

The right thing to do would be to keep UPGRADING.txt up to date *as soon
as the related code change is done*, so the documentation is fresh and
rich. Doing it just before releasing would be less effective, because
things tend to be forgotten :-) .

Vincenzo

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

Vincenzo Gianferrari Pini schrieb:
Norman Maurer wrote:
>Vincenzo Gianferrari Pini schrieb:
>
Danny Angus wrote:

10/24/06, Stefano Bagnara <apache (AT) bago (DOT) orgwrote:

I've added this point because Noel and Vincenzo brought this as an
important point in the 2.4 roadmap discussion.
I personally don't care of config.xml compatibility: I was just
reporting what I understood was important (and feasible) to the PMC.

Fair enough, in that case I direct my point to Noel and Vincezo ;-)

We just stressed the fact that life must be kept as much as possible
easy for users when upgrading to new release, otherwise they may stay
behind. Regarding configurations, this goal can be achieved either
keeping as much as possible backward compatibility for existing
features, either providing (safe and thoroughly tested) conversion
tools. But we have to be aware that slowly adding small configuration
incompatibilities can sum up to require complex conversion tools, that
nobody would develop and would become a bottleneck when releasing a
new version.

Source Communities can create better and smarter software than
Commercial Companies, but the latter normally care more of existing
"dumb" users: we should always try to reach a good compromise ;-) .

Vincenzo

>>
>Thats right but with no new features we will loose users and not get
>new I think we just need to document what to change in config.xml. I
>allready add an UPGRADING.txt to the 2.3 branch. If we add some new
>feature which need things the get changed in config.xml we just should
>document it in a UPGRADING.txt
>
The right thing to do would be to keep UPGRADING.txt up to date *as
soon as the related code change is done*, so the documentation is
fresh and rich. Doing it just before releasing would be less
effective, because things tend to be forgotten :-) .

Vincenzo

+1

Norman

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

Norman,

(I seem to have missed alot of mail, and got it all in one batch!)

I've replied about vhosting in a new thread,

I think the most problems of people are that they fear to "break"
james But why we should fear with new junit tests :-P

This is true, but it is also true that some proposals take longer and
have more impact, its not *just* about breaking James, but also about
blocking the project.
We have had some bad blocks in the past.

I think I will propose the use of the status file, and we can see what
we think once we've tried it, unless it gets shot down by the veto
brigade ;-).
Go ahead

:-)

d.

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

Stefano,

In many ways I agree with you, but I still believe that som summary
information reported in a status file, along with a record of the
decisions needed, made and outstanding, will help *you* to do the
things you want to without frightening everyone else ;-)

If we can agree on a standard workflow/usage of JIRA I would prefer it
over a status file to be committed in svn. I update JIRA when I
have no other access than http and I can't commit so I use that spare
time to update/reorganize JIRA.

I don't think the two things are really the same, and I don't think
you would be expected to replace your use of JIRA with the status
file, which is more (IM) of a summary of what the plan is, than a
detailed record of every task.

Briefly: I'm +1 to increase the usage of JIRA also for our
roadmap/status tracking. -0 on the introduction of a status file in svn.

, I'll take this on board.

d

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

10/24/06, Stefano Bagnara <apache (AT) bago (DOT) orgwrote:

I would ask you one important thing: as you talk english better than me
and you know Noel much more than me try to discuss the vhosting issue
with Noel and let's see if both of you can at least agree on a common
roadmap on this issue. you have this we can then see if this
roadmap is acceptable to me and Norman (as we are the one that put their
hands in the code until now on this issue).

I just have too much problems understanding and accepting Noel replies
to all of my message, so if you feel you can contribute on this I would
be happy.

Sorry, I started *another* thread on this issue. I think I understand
Noel's position, it is similar to mine. No doubt he can disagree with
me if he wants to.

d.

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org