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