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 16:08:57 GMT
On 9/15/06, J├╝rgen Hoffmann <jh@byteaction.de> wrote:
> Hi Bernd,
>
> Bernd Fondermann schrieb:
> > 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.

how can you say that?! you get other's and my craftship and expertise
for free! :-)

> > 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.

Everyone participating is free to put up a vote.  Why doesn't it
happen more often?

> But Eclipse is driven by companies, it is
> > like a software company.
> driven by the community though. Take jboss for another example.

Well, JBoss is not a good example. There is an open source project
JBoss and there is a company JBoss who owns (to use neutral wording)
the project.

> > 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.

I am doing project management all day, being managed all day. Sorry, I
am not able to work like that, here.
And don't get me wrong. I want to have a professional result. I want
to release often, I want cool features. But I simply cannot commit
myself to a project plan.
If we'd vote, say, to release 12th december, it would be a nice
target. But it would not have any binding in terms of delivering to
the user base.

> >> 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?

No, doesn't make sense probably. But, you see, as this community
changes, so does release management and notion thereof.

> >> 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.

-1. Not agreed. I favor all the committers working together on the
current release. We don't want to split the community up. Other
projects here at Apache are in deep, deep trouble just because of
this!

> >> 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".

To have an _opinion_ on a whish list item does not require you to have
an insight into the codebase. (Or do you know anything about
manifacturing your MP3 player which is on your personal birthday wish
list.)

> So do we/you want to deliver standards, or do you want to chase them?

Is that related to IMAP? Hopefully, this will be added soon.

> > 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 ;)

OK, I see you have your fun anyway ;-)

  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