On 9/15/06, Jürgen Hoffmann <[EMAIL PROTECTED]> wrote:
Hi to all Developers,
I have been following this thread for some time now. Being a Person
that is only watching, I came to the conclusion that You as Developers
have a totally different understanding as of what should be a 2.4
Release.
As always, well observed ;-)
Right now you are quarreling about things that should be defined once
and then be clear to everyone. Looking at the Message History,
quarreling and endless discussions are quite common to this project.
... and probably common many others here at Apache. (Some are even
worse ;-)) It is sometimes painful, but this community is not driven
by project management, it is driven by _consent_. It's not always as
pragmatic as everyone would like to have it. And there are means to
come to conclusions, mostly from shorter or longer ;-) discussions.
Votes are only the ultimate choice. This project is healthy and very
verbose in terms of communication.
Just take a second, do a quick man-power calculation and think about
how few people with very few effort (compared to other software
development) put out great software for free!
I know I am an outsider talking, but my Company is spending a certain
amount of time and money into this project by giving Norman the
opportunity to support this project (the official way).
That's really great. I'd guess you get some real value back for that!
We chose james
because we felt that James has a good codebase, and gives us the
opportunity to extend its functionality to what we need. We have a lot
of Experience in E-Mail Clusters and E-Mail Product Solutions. Nothing
was as easily extendable as james. On the Contrary, the Feature Set is
still very limited.
That said, there have been great efforts in widening this topic. Our
Companies Goal is to make the JAMES Server a State-Of-The Art E-Mail
Server which can be used as a drop-in solution with best-of-breed
solutions to common problems.
What we have found out is, that this project is willing to walk the
way with us. BUT I have also found out, that the Members are hindering
themselves to some extent by not talking objectively about certain
topics.
There is no way talking objectivly. This is our free-time dedication,
we are enthusiastic about it!
The only thing we have to adhere to is to deliver mail server software for free.
Successful Open-Source Projects (Eclipse, ...) have a strict Release
Plan (Minor Releases every 6 Months, Major Releases every Year), with a
certain set of features. The Feature Sets should be chosen, so that the release
is
possible. The Projected Release Dates are fixed to some
extend. If a Release Date is coming closer, and it is obvious that a
certain feature can not be implemented/integrated to the projected
date, there should be a vote on what to do. Move the Release Date, or
Move the Feature to the next Release Cycle.
There is some truth in this. But Eclipse is driven by companies, it is
like a software company.
We are not this way. That does not mean we aren't successfull, but
this is not an objective opinion either ;-) I am not willing to follow
strict release cycles. But it would be good to have a common
perspective. That's what is still evolving from the mailing list
discussion. It is not simply a thing of voting.
Those Rules should be clear to everyone, so noone has to argue or
quarrel about what is a next release.
That said/written please vote about how release planning should be
considered in the future.
I guess, release planning is done through discussing the topic on
public mailing lists. Not changing that, no vote needed.
I would consider the discussed road map to be the 3.0 road map,
Norman and Stefano should be responsible for its development. Features
that are wanted in 2.4 should be backported by the people that want
it within 2.4 release. Noel and Vincenzo should be responsible fpr the
2.4 release. If there are Problems during backporting/migration of
features Stefano and Norman should be available for helping, but
should keep their focus on 3.0
Well, that's not how it works. (For example, just as a side note, you
are exluding me from the list.)
We could have a "release manager" but he'd have no additional rights
than all the others.
So please step back from terms of throwing trunk on people and the
like, and keep focus on the project. Clear the misunderstandings out,
vote on release planning/cycles terminology. Keep focus on the
project in favor of interpersonal dislikings.
I really honestly see no "personal dislikings". We are (mostly) always
on subject. What you read as dislikings are different technical
opinions and goals (which will never change) and maybe some cultural
differences. But we still are a team working together on concrete
software.
Again I know I am an Outsider, but still I hope you consider my
suggestions to this project
And this is where it gets interesting. ;-)
Of course we want to hear from our user base. As a user, what concrete
features do you want in the next release? Keep on your good discussion
on the mailing list and you are no longer an "outsider".
Sorry that we aren't able to deliver more quickly, but we try to
improve. We welcome all people who'd like to contribute.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
