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. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
