Robert Burrell Donkin ha scritto:
On Mon, May 5, 2008 at 11:23 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
I will probably move to +1 once I see we are able to release at least a
first version of mailet-api, mailet-base, mailet-crypto, mailet-standard,
update the website according to this and being succesfull in this action.
In the mean time I *fear* creating so many micro libraries, so -0.
it's a train: mailet-api will have to be released first and that will
take a while but there's no reason to wait
micro-libraries are justifiably popular in the open source world.
JAMES has lots of good stuff in but it doesn't allow me to pick and
mix and comes with a huge number of dependencies.
Right. I just explained what I need to convert my -0 to +1 ;-)
Since the last public release we moved from 1 monolithic project to 2
projects (mailet+server) having 4 and 25 modules respectively. This is
already a big step,
it's not a big step: it's just moving the code around. easy enough to
move it back again.
I know this. This is why it was not a -1 ;-)
And the fact that is revertable is not enough anyway to get a +1,
otherwise we would +1 each svn commit ;-)
why don't we test this approach with a real release
process and collect feedback before moving to a 1-module-per-class
structure? ;-)
that's your itch: stratch it
I'm fine with the current number of modules, they are even too much for me.
You are collecting opinion, and all I can give is my opinion and also
add how I can change it.
You know why I'm no more active and you already know that I will not do
the release manager for anything about server. I already played in that
fire and I still feel the wounds.
You think that being monolithic was the main issue why we are not able to
release trunk, but we now have jsieve, mime4j, mailet-api that are not
monolithic and could be released but we're not releasing them, so it is not
so obvious to me.
that's mistating my position
releasing trunk requires attracting enough developers who are
interested in trunk. at the moment, there are too few developers who
are interested in trunk and too many that are concerned about quality.
this breaks down into encouraging developers to work together on the
same code (rather than in branches) and recruiting new developers.
"too many concerned about quality": can we name them? Noel for sure,
this is clear to me.. then? You? Danny? Who else?
the modular build allows developers to work in new modules rather than
forking the complete codebase on a branch. what development is
happening, is now at least happening on trunk.
factoring out stuff into independent libraries allows the code to be
shared between the 2.3.x and 3.x codebases without the need for
backports. so developers more interested in the stable release can
indirectly contribute to trunk by changing these libraries.
I understand this Robert. I just would like to see some of this to
become true before spreading your word.
JAMES has consistently failed to convert prospective developers into
committers. i accept the argument about encouraging more users but
converting users into developers but this is typically a very
inefficient process. we lack the energy to maintain a buggy codebase
and push development forward.
"consistently" ? AFAIK after I joined JAMES and I was active I helped as
much as I could Norman, Bernd and Joachim and they all become committer
or PMC members. I'm not saying that they joined james because of me, but
I think that most developers that decided to not contribute to james
between 2005 and 2007 did this because of community issues and not
because of code complexity.
You can also find other website/products explaining that they started a
different project because JAMES community was not healthy for them.
more components can help here too: it's much easier and quick to learn
a microlibrary than a large monolithic codebase.
Maybe.
On the other side I've also worked with many non-experienced developers
that really feel the pain of a multi project/multi module setup,
expecially if it is not automatic to have the whole thing imported in
their preferred IDE, and the new multimodule setup is much harder to
setup in eclipse and idea, than the monolithic one.
But we are going too far with this discussion: we simply have somehow
diverging opinions.
I just care of the results. I would simply like to see some new
committers, some new releases, some concrete result from this changes.
I will not -1, but I will not even +1 until I see it with my eyes ;-)
I already find it more difficult to find code in the current multi module,
multi project structure.
Now, often it takes me a "find" when I look for a given class, while when
we had the monolithic structure I always knew where to find each class at my
first attempt. It was easier to find references to each functions, to build
call trees and to find unused public methods.
that's because you knew the codebase well
Sure.
What I wanted to explain is a concrete change: I am an experienced james
developer: I spend much more time looking for classes than before. This
is a negative thing. I can afford this and I understand the advantages
of modularity, but I can't ignore disadvantages.
from an outsiders perspective, JAMES is too big and the packages are
too often illconceived. it takes too long to learn.
but if it offends you, stop whinging and do something about it: post a
concrete proposal.
I think you understood that I won't push anything and you know why.
Hope my -0 to +1 votes will be better than nothing. If this is worse
than nothing please tell me and I'll stop voting (or I'll find a way to
cast non-binding votes).
Furthermore (not for mailets, but about the generic micro-libraries issue)
once you extract some code to a library you "implicitly" declare a public
api, so this would mean that we are making "public" something that
previously was internal interface, so we must be ready to support that api
and its versioning.
it matters not whether the code is in a library or not. JAMES does a
very poor job in communication which interfaces will be retained
between versions and which are likely to be modified. this encourages
forks.
You are right that JAMES did a poor job, but I have had multiple james
forks in this years and it was not because of not-defined API, but
because the project was too slow in accepting patches/changes and
release them. This is only 1 fork, but this is all I can add to this
conversation because i'm not aware of live public forks or other
developers forks (escluding the famous Noel's v2.3+his dns patch).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
