james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Re: LONG JAMES v2.4 Road Map
Date Fri, 15 Sep 2006 11:56:49 GMT
On 9/15/06, J├╝rgen Hoffmann <jh@byteaction.de> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message