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.)
exactly!
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.
Juergen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
