Bernd Fondermann wrote:
On 11/7/06, Stefano Bagnara <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
