james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Hoffmann ...@byteaction.de>
Subject Re: LONG JAMES v2.4 Road Map
Date Fri, 15 Sep 2006 13:55:10 GMT
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 
>> 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 ;)


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message