On 9/15/06, Jürgen Hoffmann <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
