james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Next-major plans (was: Next 2.x release)
Date Tue, 07 Nov 2006 17:43:08 GMT
Bernd Fondermann wrote:
> On 11/7/06, Stefano Bagnara <apache@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 
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 
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: 
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:
- 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 :-)


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

View raw message