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 18:08:59 GMT
Hi Stefano, Hi Bernd,

>> >> 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!
>> I've proposed the "next-minor"/"next-major" because I don't see it as a
>> split. It is simply a group of people that put efforts to consolidate
>> some of the features we have in trunk, while new work in trunk is being
>> done.
> I am jumping on the expression "be responsible for" (which has been
> cut out by me).
> It sounds to me like a project manager's assignment. Please, let's not
> split responsability.
Well the only reason why I put this out is that it seems to me, that we 
have contributors, which have different viewpoints about what should be 
in the nexte major-/minor-/whatever release. I just wanted to *suggest* 
a way on how both parties can reach their particular goal. Nothing more.

>> Imho the 2 active trees rule we agreed in past is still valid: trunk is
>> always the main active tree. We're waiting to close 2.3 so the
>> next-minor can be started and only when next-minor will be closed we're
>> going to open the next-major release.
> Agreed. I like sandboxes, I like 2.3 branch, I like trunk. I am fine
> with all that.

So it is true? We all do want the same? :)

>> Furthermore, I already wrote that the "split" could give our users the
>> best results (3 releases in 6 months!!) and let everyone work on the
>> preferred tree.
> I am very much in doubt that those 2 additional releases will be
> possible or at least are honest goals. And if they would become
> reality, I am fearing it would become impossible to merge branches
> again.

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?

But others do. The other Party is interested into the main features, and 
wants the coming into james anywhere in the future. And they want to 
keep things stable. Watch all the important things, like JDK 
Compatibility, etc. This does not mean, that the Developers should start 
developing on 2 Branches! I see this a bit like the Linux Kernel Source 
Development. There are still Maintainers for the old 2.0 Kernel, and it 
has released some time ago. Why People still use the old Kernel? This is 
really beyond my scope. But what I am trying to say is, that there must 
be people out there still using the old Kernel, And they must have a 
reason for doing so. So the maintainer saw something great getting into 
the actual Kernel and thought, "hey, We can use that also!" So he went 
on, and backported the feature. Plain and simple.

What is important, that people agreed, that the 2.0 Kernel is not 
developed anymore, and main development should go into the 2.4 and 2.6 
kernel. So if it is clear that the Main development is being done on 3.0 
(or whatever release number) and only some features wanted, are being 
backported into the next minor 2.4 release, than there should be no more 
problems. Or do I see this totally wrong?

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

> (That said when the 2.3 release is not even through the door.)


> Let's at first work together on trunk and then decide to release (when
> time is due but quite soon).

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.

> If there are developments which are not completed, ok. Lets disable
> them, or mark them as experimental, but release what we have. Then,
> let's move on.

How does that conflict with my suggestion. You have an release. Then 
after the release, if there are bugs found, they are put into 2.3.1 or 
2.3.2 fixing the bug immediately. Main development is on the trunk. 
Features wanted in the 2.3 codebase and that should be compatible with 
2.3 should be backported from trunk.

> I am not opposing doing larger refactorings, or maybe even break
> features for a limited time. But let's move forward carefully
> nonetheless.

-1 Refactorings should be done, when they need to be done. If you keep 
on bearing with the problem, you will make the Integration harder, and 
possibly end up with never doing them.

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

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.


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

View raw message