Hi Bernd,
Bernd Fondermann schrieb:
... 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.
never said it isn't. And it is good to see that the project is active. :)
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 am a big fan of Apache, do not get me wrong. I am a strong believer
into open-source. And I personally know how difficult it is to support
the project next to the daily business.
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!
At this point in time, the amount of value put into the project is much
much greater.
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.
Well, by objective I meant, to put personal interests aside, and focus
on the problem at hand. Sometimes it seems as if there are developers
sitting and persisting on their viewpoint for days and weeks. That is
not helping the problem at hand, Hopefully I could get this point across
now.
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.
driven by the community though. Take jboss for another example.
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.
Well from my Point of View there are certain standards on how to plan
releases and release cycles. Instead of re-inventing the wheel, I
suggest to vote for a proven method. If it is Method A or B is not
important to me. That everyone knows and understands it, is more important.
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.
So you are saying that it makes more sense to discuss how to do the next
release each and every time a release was made?
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.
Bernd, this was by no means to be understood as an offense or anything
against other active contributors on this project. This List is neither
complete nor a concrete suggestion. Replace the Names in the Lists with
A, B, C, and D.
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".
Features that I want into the next release are many. Most of Norman
knows about. Will they be in the next release? I do not know. And this
is because I think I may not decide on what should go into the next
release. I have not enough inside into the codebase. All I know is that
the E-Mail Standard will change rapidly in the next years, starting with
big companies deploying their "Standards".
So do we/you want to deliver standards, or do you want to chase them?
Sorry that we aren't able to deliver more quickly, but we try to
improve. We welcome all people who'd like to contribute.
If the day had 72 hours, I'd be a contributor. Believe me ;) But 4 Kids
are a time eating business ;)
Jürgen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
