You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stefano Bagnara <ap...@bago.org> on 2006/11/07 18:43:08 UTC
Next-major plans (was: Next 2.x release)
Bernd Fondermann wrote:
> On 11/7/06, Stefano Bagnara <ap...@bago.org> wrote:
>> I could spend hours explaining why this statistic are meaningless, but I
>> think I should concentrate my effort proving you wrong on the
>> "battlefield" ;-)
>>
>> I agree with you that we'll have a better overview only when we'll
>> merge, but we're in roadmap and we'll branch at most in 2 months.
>
> Why branch as early as that? Why even decide on this now? Anyone
> _right now_ planning to do work on trunk not intended for the next
> release?
_Simply_ because dates were part of the proposal, and we voted it. Feel
free to make a different proposal if you think there's a better approach
:-)
>> I
>> think we should try to branch already in december, and delay to jan 2007
>> *only* if we can be sure a missing critical feature will be ready by
>> that day, otherwise we should branch without that feature.
>
> What are the planned features? Which are "missing critical"? What even
> is the "mission", beyond improving James?
> This is a complete abstract discussion to me at this point given the
> 50+ JIRAs and maybe other things not even contained in JIRA. Please
> enlighten me.
I think I wrote my idea about this a lot of times, and I also sent a
status update on the list ;-)
The constraints are:
1) backward compatible config.xml: next-major "boots" with the old
config.xml in a backward compatible way.
2) backward compatible storage (next-major) share the same storage as
previous.
3) ETA dates: of course we can try to enforce the branch date, while the
real release date will be a function of number of testers, number of
bugs found, number of committers that fix bugs.
Everything we have in trunk now should be (we have to confirm this, but
I guess this is currently true) compliant with the constraint above.
Imho we already have a cool feature set for that release, but we take
1-2 months to see if something else can be included before branching and
starting to consolidate the code.
I can go further listing the issues I would try to include working
actively on them:
JAMES-52 8bitmime capabilities missing
JAMES-595 Change names of release artifacts to use james-server instead
of james.
JAMES-675 Add search-domain configurability to DNSServer
JAMES-676 make it optional for DNSServer to override static
Resolver/Cache for dnsjava Lookup object
I also have a set of features already coded that I have to test much
more to see if they can be committed to trunk, and this depends on how
much time I'll have before the branch:
JAMES-134 Large emails in the spool cause SpoolManager to throw
OutOfMemoryError
JAMES-241 fail gracefully upon large messages/attachments
JAMES-288 memory efficient retrieval
JAMES-491 SpoolManager refactorings
JAMES-520 Create a RemoteDelivery service
Some other issue is to be completed, but already there and probably working:
JAMES-415 Dynamic reload for some configuration of main services (e.g:
servernames)
JAMES-643 Replace all java.net.InetAddress usage with dnsjava
JAMES-622 move ignoreCase configuration to the UsersRepository and
remove containsIgnoreCase
I hope someone will find the time to test some more IMAP so to be able
to include the imap references in the config.xml marked as experimental
and give some hints on its usage (imho it will be good to have
experimental code out in a release before refactoring it for the
following release)
I have concerns about handler apis, because I don't know too much that
part (never found the time to study handlerapi currenlty in trunk and
the differences currently in the branch) and I know that handlerapi-v2
(the branch) is not complete. It would be cool to have a solid,
definitive handler api for the next-major release, but I think this
should not be a show stopper: if we can do this fine, otherwise we'll
delay it to the following release.
Reading what's going on on the mailet api side I think that we won't
include any change on mailet apis in next-major. The current proposal is
a strawman implementation and it needs a full non backward compatible
rewrite of the server.
It would be cool if anyone else could create a similar list.
>> I won't bet the farm about the release date, but I'll work for that to
>> happen, and I expect the same from all other committers but you (as they
>> replied +1 to the next-major plans).
>
> Jeez, what is so important about that date? - Of course I agree to
> release more often than we did. Every 6 month seems absolutly
> reasonable to me.
> Maybe March is OK, too - but this is completely depending on the
> feature set and the status of the application at that point in time.
I think we had 2 options to define when to branch:
a) define a date for branching and try to have a consistent feature set
for that date
b) define a feature set and wait for the date it is completely
implemented to branch.
I had the impression that "b" was not feasible because the james pmc is
not a company and imho is not able to coordinate such an effort where
"date" is less than 2 years since the last release, so I proposed to
follow the "a" style.
Maybe this is not the preferred way, but this is what I proposed and
what I thought has been voted with an unanimous +1. I'm a bit embarassed
by this thread now.
>> As we expect it to be out really soon, can you give us more details on
>> features you plan to backport?
>
> Who is "we"?
"We" is at least me and Norman, and everyone having read the thread
where Noel and Vincenzo discussed of that release.
Read the whole "JAMES 2.4 Road Map" thread and you will find Noel
saying: "if we do it my way, we can release 2.4 in less than 2 months."
That message is dated 13/Sep so I thought that Noel plans was to have
that release out the next week ;-)
> Sorry, I don't want to get into a fist fight here, so please let's
> take a step back.
No fight from me, just trying to understand what is your opinion, as I
understand that I misunderstood your vote ;-)
Sincerely, I just want to find consensus on some roadmap and to keep
working toward a goal: a release.
I said I won't support next-minor because I think we have quality code
in trunk and I think I should spend my time consolidating all of it and
not part of it: working on next-minor would delay next-major and all the
following releases, and in the last year I already spent too much time
working on consolidation of an "outdated" release (outdated means to me
that I already have to use trunk because many features I need are there).
I would have skipped also next-major concentrating all the efforts on
next-greater but I think that this is too much for the next release and
removing the "backward compatibility" constraint I added to "next-major"
would mean we have to start discussing how to do new things, and this
will delay next-greater to 2010 ;-) .
> We have decided and agreed about the general direction, this is very good.
> Now let's go to work and see where it gets us.
> At any point in time we can get back to discussion and adjust our
> yet-not-so-complete roadmap.
>
> Bernd
Can you write what you think "we" have decided as I understand you don't
feel you have decided the following:
------------
"next-major":
- based on current trunk
- storage and config.xml compatible with 2.3.0
- ETA: branch on Dec 2006/Jan 2007, release on Mar 2007
---------
Imho this means: if you have something you want to include in next-major
and it is storage and config.xml compatible with 2.3.0 you have to hurry
because we have a dead-line in 1-2 months :-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Next-major plans
Posted by Danny Angus <da...@gmail.com>.
> Gossip: I read Andy's blog, if I remember correctly he's no more the
> JBoss Mail Server guy.
Thats right, but I've known Andy for a while and we don't always
agree, so getting consensus between the two of us is an indication
that the proposals might satisfy both James and non-James
applications.
> I review every of your commit :-) You know I "hate" JNDI, but I think
> there are also good things in your commit.
> - I like the MailFactory
Thank you, I've meant to do that since *forever* but never got round to it.
> - I like the string based lookup for repositories
looking up repositories is one thing which we do over and over again,
so I figure it is a good candidate for making it easy. What we need to
do is to ensure that it continues to apply to the masilbox manager
strategy, and that the API doesn't need to contain any knowledge of
James naming strategy. At most just mailet config params
> - I don't like a rich "User" object in the API
No neither do I! I'm working on a completely new model of
users/accounts/domains/addresses to replace it with but I'm going
round in circles.
> - I like the DataSource change,
Yeah, we need to support drivers which already offer
javax.sqlDataSource implementations (e.g Oracle)
> - I don't like the MailetContext => JNDI context move for simple value
> like HELLO_NAME and DEFAULT_DOMAIN (more code needed, less clear)
Yeah, I'm not too happy with it either but I'm not decided about what
would be good, we need to ensure that we don't prescribe (force on
people) a closed set of parameters.
Perhaps "Properties MailetContext.getProperties()" might be the answer.
>
> I have technical concern behind "likes" and "dislikes", but I think I
> said most of them, and I can give further details on demand.
> Hope this is a useful and clear summary of my view.
Yes great.
> I wrote a bunch of times that I guess your Mailet APIs proposal do not
> belong to next-major (backward compatible / branch in 1-2 months)
> release, but more probably to the following one.
> Can you confirm this? If so, please record this in the STATUS ;-)
At the moment there is no decision on what the changes will be, when
there is we can talk about timing.
> When you wrote this I already updated that file including this data:
Yes I saw that, thank you and well done.
> the
> question now is "do we agree that we've agreed" ? ;-)
> I thought we agreed but Noel for sure "ignore" this, and Bernd raised
> some concern on the hardness of the dates: do we need another
> discussion? Do we need another vote to really understand what we want to
> do? I'm lost, please help.
I think that if you have called a vote and recorded the result then we
have agreed.
If there is still doubt or disagreement I suggest we discuss it in a
separate thread on general@ because that is a PMC matter.
However I think that it might help if we could formulate some simple
VOTEs to clarify each point separately. I'll look into this.
d.
Re: Next-major plans
Posted by Danny Angus <da...@gmail.com>.
> Gossip: I read Andy's blog, if I remember correctly he's no more the
> JBoss Mail Server guy.
Thats right, but I've known Andy for a while and we don't always
agree, so getting consensus between the two of us is an indication
that the proposals might satisfy both James and non-James
applications.
> I review every of your commit :-) You know I "hate" JNDI, but I think
> there are also good things in your commit.
> - I like the MailFactory
Thank you, I've meant to do that since *forever* but never got round to it.
> - I like the string based lookup for repositories
looking up repositories is one thing which we do over and over again,
so I figure it is a good candidate for making it easy. What we need to
do is to ensure that it continues to apply to the masilbox manager
strategy, and that the API doesn't need to contain any knowledge of
James naming strategy. At most just mailet config params
> - I don't like a rich "User" object in the API
No neither do I! I'm working on a completely new model of
users/accounts/domains/addresses to replace it with but I'm going
round in circles.
> - I like the DataSource change,
Yeah, we need to support drivers which already offer
javax.sqlDataSource implementations (e.g Oracle)
> - I don't like the MailetContext => JNDI context move for simple value
> like HELLO_NAME and DEFAULT_DOMAIN (more code needed, less clear)
Yeah, I'm not too happy with it either but I'm not decided about what
would be good, we need to ensure that we don't prescribe (force on
people) a closed set of parameters.
Perhaps "Properties MailetContext.getProperties()" might be the answer.
>
> I have technical concern behind "likes" and "dislikes", but I think I
> said most of them, and I can give further details on demand.
> Hope this is a useful and clear summary of my view.
Yes great.
> I wrote a bunch of times that I guess your Mailet APIs proposal do not
> belong to next-major (backward compatible / branch in 1-2 months)
> release, but more probably to the following one.
> Can you confirm this? If so, please record this in the STATUS ;-)
At the moment there is no decision on what the changes will be, when
there is we can talk about timing.
> When you wrote this I already updated that file including this data:
Yes I saw that, thank you and well done.
> the
> question now is "do we agree that we've agreed" ? ;-)
> I thought we agreed but Noel for sure "ignore" this, and Bernd raised
> some concern on the hardness of the dates: do we need another
> discussion? Do we need another vote to really understand what we want to
> do? I'm lost, please help.
I think that if you have called a vote and recorded the result then we
have agreed.
If there is still doubt or disagreement I suggest we discuss it in a
separate thread on general@ because that is a PMC matter.
However I think that it might help if we could formulate some simple
VOTEs to clarify each point separately. I'll look into this.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Next-major plans
Posted by Stefano Bagnara <ap...@bago.org>.
Danny Angus wrote:
> On 11/7/06, Stefano Bagnara <ap...@bago.org> wrote:
>
>> Reading what's going on on the mailet api side I think that we won't
>> include any change on mailet apis in next-major. The current proposal is
>> a strawman implementation and it needs a full non backward compatible
>> rewrite of the server.
>
> I hope that over the next week or so I will be in a position to make
> some detailed proposals about the API. Andy Oliver has been great to
> bounce ideas off.
Gossip: I read Andy's blog, if I remember correctly he's no more the
JBoss Mail Server guy.
> The fork is indeed a straw man, but please note that it isn't just the
> API thats being changed, I'm testing my ideas out by changing the
> server as well. In fact the head of the fork builds and runs with a
> fairly comprehensive array of mailets deployed. One of my aims is to
> ensure that James can be modified without too much pain to support the
> API changes.
I review every of your commit :-) You know I "hate" JNDI, but I think
there are also good things in your commit.
- I like the MailFactory
- I like the string based lookup for repositories
- I don't like a rich "User" object in the API
- I like the DataSource change,
- I don't like the MailetContext => JNDI context move for simple value
like HELLO_NAME and DEFAULT_DOMAIN (more code needed, less clear)
I have technical concern behind "likes" and "dislikes", but I think I
said most of them, and I can give further details on demand.
Hope this is a useful and clear summary of my view.
> I'd also like to move the API out to its own sub-project before we
> change it, so that the API can be released with a test-bed of some
> kind to allow mailet authors to change their mailets before they
> upgrade the server, and to allow Server to upgrade to support the API
> changes at its own pace, and not forced by the pace of change of the
> API.
I wrote a bunch of times that I guess your Mailet APIs proposal do not
belong to next-major (backward compatible / branch in 1-2 months)
release, but more probably to the following one.
Can you confirm this? If so, please record this in the STATUS ;-)
>> Can you write what you think "we" have decided as I understand you don't
>> feel you have decided the following:
>> ------------
>> "next-major":
>> - based on current trunk
>> - storage and config.xml compatible with 2.3.0
>> - ETA: branch on Dec 2006/Jan 2007, release on Mar 2007
>> ---------
>
> Please people, if we think we've agreed something record this stuff in
> the STATUS file then we can stop discussing it and move forwards. :-)
>
> d.
When you wrote this I already updated that file including this data: the
question now is "do we agree that we've agreed" ? ;-)
I thought we agreed but Noel for sure "ignore" this, and Bernd raised
some concern on the hardness of the dates: do we need another
discussion? Do we need another vote to really understand what we want to
do? I'm lost, please help.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Next-major plans (was: Next 2.x release)
Posted by Danny Angus <da...@gmail.com>.
On 11/7/06, Stefano Bagnara <ap...@bago.org> wrote:
> Reading what's going on on the mailet api side I think that we won't
> include any change on mailet apis in next-major. The current proposal is
> a strawman implementation and it needs a full non backward compatible
> rewrite of the server.
I hope that over the next week or so I will be in a position to make
some detailed proposals about the API. Andy Oliver has been great to
bounce ideas off.
The fork is indeed a straw man, but please note that it isn't just the
API thats being changed, I'm testing my ideas out by changing the
server as well. In fact the head of the fork builds and runs with a
fairly comprehensive array of mailets deployed. One of my aims is to
ensure that James can be modified without too much pain to support the
API changes.
I'd also like to move the API out to its own sub-project before we
change it, so that the API can be released with a test-bed of some
kind to allow mailet authors to change their mailets before they
upgrade the server, and to allow Server to upgrade to support the API
changes at its own pace, and not forced by the pace of change of the
API.
> Can you write what you think "we" have decided as I understand you don't
> feel you have decided the following:
> ------------
> "next-major":
> - based on current trunk
> - storage and config.xml compatible with 2.3.0
> - ETA: branch on Dec 2006/Jan 2007, release on Mar 2007
> ---------
Please people, if we think we've agreed something record this stuff in
the STATUS file then we can stop discussing it and move forwards. :-)
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org