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 19:58:31 GMT
On 9/15/06, J├╝rgen Hoffmann <jh@byteaction.de> wrote:
> Hi Stefano, Hi Bernd,
>

> this is exactly why there should be certain assignments ( I did not use
> "responsibilities" with a purpose ;) ) I see two parties right now. One
> that ones to do the big thing, work on the next major release, and the
> other party that just wants to do minor/little changes, and release
> that. Which is fine. Why should the guys developing the main features
> decide on what goes into the minor changes and what does not. In fact
> they really do not care, do they?

I care.

You are stating we have two parties, with two different goals? And you
are seeing that as a problem for the project? Then you suggest those
two parties would get around each other easiest by everyone doing
there own thing?

I don't think this is true. Instead:
We have a bunch of people, having one goal, developing James. Everyone
is having its own thoughts about reaching that goal. Everyone can
commit code to trunk or supply patches. That's where it gets tricky.
Because most code is liked, but some isn't, discussions raise up.

You say: Discussion have to be fruitful. I say: Damn right!

Those have to come to a conclusion. Conflicts have to be resolved. Not
circumvented.
This is what this project is essentially all about. Not about
branches, timelines, vetoes, assignments, parties and whatnot. (I am
not totally sure about parties. We should have a release party soon!
;-) )

> > What makes me suddenly think that people want to accelerate
> > development and releases like mad when some month ago they didn't care
> > much about releasing at all?
>
> It is not acceleration. It is planning. It is Feedback to the Users. It
> is showing confidence. It is by no means about acceleration. As I said
> the dates are not to be put into concrete ( German saying, don't know if
> that maps to the english language ;) ). It just represents a goal, each
> contributer commited to. It just says, "We plan to put this and this
> feature set into the release." If we see that we cannot meet the goals,
> we can still decide on leaving it out or move the release date.

Can't argue with you on this one. Exept that I cannot commit myself to
anything but the next task. Sometimes not even that. I only can
volunteer. And commit to svn of course.

> How do you want that to be done, if you have developers that want to
> achieve different things? They will be vetoing changes etc. I do not
> even know if we are fine with sandboxes. At least I recall that there
> was some discussion about the topic.

A veto is there to be resolved, not to postpone or block changes.
Anything else would is a misuse.

> >> >> 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.
> >>
> >> Unfortunately I guess that IMAP won't be included in next-minor or
> >> next-major, but we can only expect to be able to do some steps in that 2
> >> releases (it would be *really* cool if we were able to put experimental
> >> unstable support for imap in next-major but this is not realistic to
> >> me).
>
> IMAP? This is not what I meant by *setting* a standard? It is a standard
> for Years. This is an example of chasing it ;) spf, surbl, greylisting,
> sieve, tight integration into existing business environments is what i
> am talking about. There is not even a solid Alias/Forward/Virtual Domain
> Implementation. As far as I can tell, James is far away from being a
> standalone Business Ready Mail Server Solution, As opposed to a very
> good Relaying, Mail Processing Solution.

Well, this is a volunteer-driven project. I am all for that. Not
opposing anything.
But also not trading new features for quality. No bad fast hacking
here. That is done somewhere else. (Well, I am not totally sure where,
but must be somewhere ;-) )

> I see a great future for the project by setting standards, because I
> feel that the E-Mail Standard is finding itself new. It is getting more
> and more important to fight spam and other email related problems
> without changing the existing infrastructure.
>
> I believe we can set Standards with James. Instead of chasing them.

I like that. Let's keep the team working together and other will join us.

  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