You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2006/09/12 20:08:32 UTC
JAMES v2.4 Road Map
Norman Maurer wrote:
> > > Personally, I'm ready to make it a release, and start work on 2.4,
which
> > > should be a careful selection of things to add, not a core dump from
trunk.
> > We never agreed on this roadmap. And I think I won't agree on this
> > approach even later.
> I agree with Stefano. For me we should use the current trunk as 2.4
> ( with handler-api2 merged when its complete). I don't see any
> problems with it. We don't did "critical" changes which whould break
> compatibly.
It should still be a careful selection. As I said long ago, if you want to
move trunk to 2.4, we should review every difference. Then, if we agree
that each one represents a suitable risk/reward, fine.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map
Posted by Stefano Bagnara <ap...@bago.org>.
Vincenzo Gianferrari Pini wrote:
>> Furthermore I want to let you know that the new fastfail stuff need
>> changes to configuration files and would no allow conditions (ii) and
>> (iv), so using your numbering scheme would not be suitable for 2.4.
>
> My point is (without integralism) to be able to get 2.4, and have my
> production system run doing the same things as before with no or at
> least little effort (no or very little changes to configuration) and
> then, when I'm confortable, start exploiting the new features by
> changing the configuration files. By little effort I mean also the
> ability to easily rollback if weird things happen. And you know that
> going from 2.2 to 2.3 was not simple at all!
> *If* those things turn out to be impossible, then obviously we will
> follow your and Norman's roadmap :-) . But *if* it is feasible, as also
> Noel thinks, this is my choice.
As a note, the new fastfail stuff needs also changes to the
assembly.xml, so even if the config.xml could be kept compatible this
would not be the same for assembly.xml.
This is not to say that you don't have to follow that roadmap (as I said
I'm happy if you produce an interim release and I don't have to put my
efforts for this to happen), but to give you more information on what
you can expect to achieve.
Stefano
--
PS: is weird how having the componet assembly in xml instead of
hardcoded in a file is creating incompatibility issues that we wouldn't
care of otherwise. We should keep this in mind when/if we'll ever move
to another container.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map
Posted by Norman Maurer <nm...@spam-box.de>.
Bernd Fondermann schrieb:
> On 9/14/06, Noel J. Bergman <no...@devtech.com> wrote:
>> I will read and reply to the various comments later, but I want to
>> put some
>> figures into the picture.
>>
>> $ du -hs branches/v2.3/src/java trunk/src/java
>> 13M branches/v2.3/src/java
>> 15M trunk/src/java
>>
>> $ svn
>> diff
>> --old=https://svn.apache.org/repos/asf/james/server/branches/v2.3/src/j
>> ava \
>>
>> --new=https://svn.apache.org/repos/asf/james/server/trunk/src/ja
>> va >diff.txt
>>
>> $ ls -l diff.txt
>> -rw-rw-r-- 1 noel noel 2056010 Sep 14 13:19 diff.txt
>>
>> So there are 2MB worth of differences in the Java code between trunk and
>> v2.3. Some of the 2MB are overhead in the diff format, some are license
>> headers, some are refactoring, some are more substantial and functional
>> changes.
>>
>> I am *not* willing to effectively accept blindly changes of roughly
>> 15% (and
>> that's only the current stuff, not including major new development) of a
>> stable codebase. I *am* willing to go through it with everyone,
>> change by
>> change, and decide what is reasonably safe to add in the short term, and
>> what needs much more attention for a later merger.
>
> I am having a hard time understanding this. Do you say, that all
> commits in current trunk since branching have a silent -1 from you?
> What specific changes do you object?
>
> I think there are enough eyeballs constantly monitoring trunk, which
> does not mean to _release_ it blindly without testing. But having an
> audit on a commit-per-commit basis makes no sense, since many of them
> where applied to 2.3 branch anyway. The rest simply has to be tested.
I fully agree on this. I review every commit. I think every commiter
should try todo it. If i see any problems with a commit i whould raise
my voice.
>
>
> This is also the reason for me to propose following our original
> reasoning when branching 2.3 (read: not 2.x-branch, but 2.3.x-branch):
> This is the maintainence branch where we apply bugfixes for 2.3.x.
> Fixes are isolated, well tested and thus a branch is maintainable.
>
> Bernd
Agree..
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map
Posted by Bernd Fondermann <be...@googlemail.com>.
On 9/14/06, Noel J. Bergman <no...@devtech.com> wrote:
> I will read and reply to the various comments later, but I want to put some
> figures into the picture.
>
> $ du -hs branches/v2.3/src/java trunk/src/java
> 13M branches/v2.3/src/java
> 15M trunk/src/java
>
> $ svn
> diff --old=https://svn.apache.org/repos/asf/james/server/branches/v2.3/src/j
> ava \
> --new=https://svn.apache.org/repos/asf/james/server/trunk/src/ja
> va >diff.txt
>
> $ ls -l diff.txt
> -rw-rw-r-- 1 noel noel 2056010 Sep 14 13:19 diff.txt
>
> So there are 2MB worth of differences in the Java code between trunk and
> v2.3. Some of the 2MB are overhead in the diff format, some are license
> headers, some are refactoring, some are more substantial and functional
> changes.
>
> I am *not* willing to effectively accept blindly changes of roughly 15% (and
> that's only the current stuff, not including major new development) of a
> stable codebase. I *am* willing to go through it with everyone, change by
> change, and decide what is reasonably safe to add in the short term, and
> what needs much more attention for a later merger.
I am having a hard time understanding this. Do you say, that all
commits in current trunk since branching have a silent -1 from you?
What specific changes do you object?
I think there are enough eyeballs constantly monitoring trunk, which
does not mean to _release_ it blindly without testing. But having an
audit on a commit-per-commit basis makes no sense, since many of them
where applied to 2.3 branch anyway. The rest simply has to be tested.
This is also the reason for me to propose following our original
reasoning when branching 2.3 (read: not 2.x-branch, but 2.3.x-branch):
This is the maintainence branch where we apply bugfixes for 2.3.x.
Fixes are isolated, well tested and thus a branch is maintainable.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map
Posted by Bernd Fondermann <be...@googlemail.com>.
On 9/15/06, Vincenzo Gianferrari Pini
<vi...@praxis.it> wrote:
> Stefano Bagnara wrote:
>
> > Vincenzo Gianferrari Pini wrote:
> >
> >
> > It's more than one year that I write to this list, you should have
> > learned that my discussion are a little rude. Don't take it so hard.
>
> Ok :-) . But we italians (especially we "emiliani" and "romagnoli") have
> sometimes to remember that we have "sangue caldo" ;-) . And the language
> doesn't help.
:-) ... my salt pot is always right here, just for the "grain of
salt" ;-) everyone reading apache lists has to have one! keep in
mind, still not everybody has.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map
Posted by Stefano Bagnara <ap...@bago.org>.
Vincenzo Gianferrari Pini wrote:
>> I think that you can create a new version in jira and call it
>> "next-minor" and make a list of things you want to merge back in this
>> release. I hope it is fine for you if I won't work on this branch and
>> to agree that this release should not block trunk development or the
>> start of the "next-major" release.
>
> I agree. But, if the next-minor is worth doing, we all need some of your
> and Norman's help. Otherwise it probably can't be done.
I already said that I won't work for the next-minor.
At my best I could help you with the website stuff (as I refactored all
and maybe I better know the new maven2 site builds), with the maven spf
builds (but I need an answer to my repository proposal and if no answer
I need Noel to setup the svn notifications so I can really work on james
repository) and few other things. I'm not ready to test that releases or
to look for bugs in that release. Btw if you find a bug in "next-minor"
and the bug is also in trunk (as when we'll start next-major, next-minor
should be already closed), as always, I'll put that on top of my priorities.
>> I'm not trying to convince anyone, and I'm simply trying to define
>> something that works for me. If you say something that I think is not
>> correct I tell you: this is the way I discuss. I think I worked much
>> more than most of other committers on the James code in the last year
>> so I think that you may not have the same visibility I had on some of
>> the code that has been included in trunk and 2.3 branch, and that's
>> why I write them here. Take into consideration that I will always read
>> and try to understand your point: this doesn't mean I change my ideas
>> easily, but I change them very often (only stupids never change idea).
>
> "I perfectly know that I don't know perfectly" the new code (Socrates
> teaches ;-) ), and this is the reason why I'm now wary and
> conservative, and want to be assured and convinced by you (the one that
> knows the most about the new code) and by Noel (the one that has the
> widest knowledge of the James code in general) about how sound and
> feasible and costly and safe is to build the next-minor release (that we
> all agree that would be worth doing) from the 2.3 branch. And this is
> the kernel of the discussion going on between you and Noel, that I'm
> observing to build my final choice.
I never agreed that "it WORTH doing": I said that it would be a good
thing to James project and to James users, but I think that it does not
worth the efforts and this is the very reason why I say I will work on
next-major and not on next-minor. If the efforts are not mine, then I'm
really happy with a next-minor release.
I think that a +1 should always means I will work for this to happen,
and a +0 is it's ok for me but I won't actively help. I'm simply +0 for
the next-minor and +1 for the next-major.
> And I would like to hear something from Serge, Danny and the others,
> because this is going to be a very an important decision.
Well, I always welcome involvement in votes and code, but I think this
is not a so big decision: if you fill you can do the next-minor work on
it. If it is feasible it will be done, otherwise we have the next-major
on the road.. so no big problems either way.
>> It's more than one year that I write to this list, you should have
>> learned that my discussion are a little rude. Don't take it so hard.
>
> Ok :-) . But we italians (especially we "emiliani" and "romagnoli") have
> sometimes to remember that we have "sangue caldo" ;-) . And the language
> doesn't help.
Right, I'm much more polite (sometimes) when I speak italian.
>> [...]
>> I simply think that with almost the same efforts needed to release
>> 2.3+new improved fastfail (next-minor) we would release the
>> "next-major" because that one is one of the few things that still
>> deserve much attention.
>
> And *this is the key point* :-) .
>
> As an alternative approach, what would you think about not backporting
> the new improved fastfail to 2.3, but instead backporting the new
> filters (like spf, graylisting etc.) to the "old fastfail" availble in
> 2.3? Would it be simpler and safer or not?
Maybe Norman has a better overview of this.
I always thought and said that fastfail in v2.3 should have not been
included or marked as experimental because I know that it was not our
final solution and we would have broken backward compatibility later, so
I'm not so happy in releasing a new minor release just to improve an
experimental feature, but I could leave with it (-0).
I really don't know what are the efforts and the risk of backporting the
additional filters to the old fastfail pattern. Never thought at this
possibility but as a first guess I don't think this is a better approach.
>> I still run heavily modified local branches and my main reason for
>> being a committer to james is reduce my costs to keep them updated by
>> sharing my work with the community: 2.3 has been a failure in my
>> roadmap, I simply can't put more efforts in a conservative release.
>
> But probably the next-minor would be impossible to create without some
> of your and Norman's help.
Well, I already said this, and this is not a thing to vote on: I will
help for next-minor stuff *only* for things that are in next-major
roadmap. I will be happy to change next-major roadmap priorities trying
to put first the things you need for next-minor (but I'm not involved in
the handerchain refactoring stuff, that I say is the critical part of
the current trunk vs 2.3).
>> [...]
>> At that time I always said: simply decide when to branch and I'll help
>> with bug fixes but not with the other release issues. I did much more
>> than this. I fixed our package build, updated the website, fixed the
>> licesing issues and so on... I don't know why you never understood
>> that it was a matter of branching. I simply didn't agree to stop
>> working on trunk to let the code consolidate itself.
>
> All true. In fact we had to "force" you somehow to help coming out with
> 2.3, and btw you and Norman worked much more than me also in the last
> tasks for 2.3 :-) . Btw, I hope that with rc3 we are finally done!
I never vetoed a proposal to branch the trunk. And I never had to be
convinced to remove a veto. I don't feel I've been forced to branch. I
know you tried to force me to stop working on trunk and I was really
against this, but this has nothing to do with branching 2.3. I'm still a
little hurted by the whole things that made me stop committing for a while.
>> I don't think that this is a generally valid approach but this time we
>> are talking about few efforts and not overriding each other. I have to
>> admit that if Norman was on the "next-minor" boat and against the
>> "next-major" I would have thought much more before proposing to try
>> following both, but I learned to work very well with Norman while I
>> have much more "discussion" problems with the other PMC committers (I
>> know this is a limit of mine) so the "split" thing make sense to me.
>> It seems that everyone can work on what he thinks it's better: and
>> opensource world works better when the project goals matches personal
>> goals.
>
> But a total split would be not good. As said above we need some help
> from you and Norman for next-minor, and for example the areas where I
> can mostly help are independent from the split...
I wrote what I can do and what I won't do, I also wrote my votes (and no
vetoes are there). So I think that the choices about "next-minor" now is
not mine.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Stefano Bagnara wrote:
> Vincenzo Gianferrari Pini wrote:
>
>>> Yes, but we already used a different scheme for 2.1, 2.2 and 2.3..
>>> so why change it for 2.4?
>>
>>
>> Because IMHO it was wrong :-) .
>
>
> Ok, What I'm trying to say that consistency helps understanding: if
> you change the rules in the middle you don't help people.
> And if you really have to change the rule for the next minor why don't
> we change the yet-to-be-release 2.3?
> I simply say that imho this discussion does not belong to a 2.4.
My intent is to stress that IMO, for our project, a "next minor" release
should not be just a subset of features of a "next major" release, but
that there are some compatibility/ease-of-install/risk differences from
the point of view of the user, that could drive/justify one branching
strategy or another. The numbering scheme is just a suggestion on how to
evidentiate it, but is not the substance :-) .
>
>>> Anyway, I always said that I don't care about the number while
>>> discussing, I just care about what we release and when. So we can
>>> even talk about "the next release" and skip the number if this helps
>>> (we'll vote the number just before the release).
>>>
>>> 2.x releases have been storage compatible in past, so I think we can
>>> safely put in the 2.x scheme every future storage compatible release
>>> and keep 3.0 for bigger steps, but mine is only a +1 vs +0, no
>>> vetoes about this meaningless thing: we need code to make releases,
>>> not numbers.
>>
>>
>> Not only storage compatible, but also configuration compatible etc.
>> About numbering, it is like naming: helps in stating things.
>> And please breathe a second and take it easy before ironizing and
>> telling other people that they say meaningless things etc. You won't
>> convince anybody this way, you will only put them off.
>
>
> This is not true: 2.x releases have been only storage compatible. I
> had to upgrade config.xml for evey second-digit step from 2.0 to 2.1.*
> to 2.2.0 to current 2.3.0rc3.
I know. In fact I'm stressing the compatibility/ease-of-install/risk
issue (see above) as something to take care of, for our users sake (*we*
committers don't have too many problems of this kind).
>
> I don't say that what you say is meaningless, I say that numbering is
> meaningless in a roadmap: a roadmap should include features, maybe
> dates, but numbers are simply labels used to understand each other.
Right. see above.
>
> So my proposal is to choose 2 names: one for the release you and Noel
> are proposing and that will be a branch of 2.3.0 with a few features
> from trunk to be released before the end of november and the other for
> the release I and Norman want to work for and to be branched from
> trunk at start of January 2007 and released in March 2007.
>
> I removed the (unused) 2.4 tag from our JIRA and renamed the 3.0 tag
> to "Trunk" so that we don't introduce much more confusion. We marked
> things resolved against 3.0, it is better to say that we resolved them
> in trunk so we can rename trunk to something else when we'll branch.
> My fantasy is limited so I would define then "next-minor-release" and
> "next-major-release" (and we could have a "next-greater-release" for
> storage incompatibility and other major changes).
>
> I think that you can create a new version in jira and call it
> "next-minor" and make a list of things you want to merge back in this
> release. I hope it is fine for you if I won't work on this branch and
> to agree that this release should not block trunk development or the
> start of the "next-major" release.
I agree. But, if the next-minor is worth doing, we all need some of your
and Norman's help. Otherwise it probably can't be done.
>
> I'm not trying to convince anyone, and I'm simply trying to define
> something that works for me. If you say something that I think is not
> correct I tell you: this is the way I discuss. I think I worked much
> more than most of other committers on the James code in the last year
> so I think that you may not have the same visibility I had on some of
> the code that has been included in trunk and 2.3 branch, and that's
> why I write them here. Take into consideration that I will always read
> and try to understand your point: this doesn't mean I change my ideas
> easily, but I change them very often (only stupids never change idea).
"I perfectly know that I don't know perfectly" the new code (Socrates
teaches ;-) ), and this is the reason why I'm now wary and
conservative, and want to be assured and convinced by you (the one that
knows the most about the new code) and by Noel (the one that has the
widest knowledge of the James code in general) about how sound and
feasible and costly and safe is to build the next-minor release (that we
all agree that would be worth doing) from the 2.3 branch. And this is
the kernel of the discussion going on between you and Noel, that I'm
observing to build my final choice.
And I would like to hear something from Serge, Danny and the others,
because this is going to be a very an important decision.
>
> It's more than one year that I write to this list, you should have
> learned that my discussion are a little rude. Don't take it so hard.
Ok :-) . But we italians (especially we "emiliani" and "romagnoli") have
sometimes to remember that we have "sangue caldo" ;-) . And the language
doesn't help.
>
>>>> So this is how I think 2.4 should be: useful things that deserve
>>>> and *can* be added to 2.3 in a short time frame, without too much
>>>> work: very first among others the new fastfail (*if* the "without
>>>> too much work" applies). "Time driven instead of feature driven"
>>>> for minor releases.
>>>
>>>
>>> If we take everything we have in trunk now and compare with 2.3 I
>>> think that fastfail is one of the few things that cannot be
>>> backported as is. As I already wrote we have uncomplete code both in
>>> trunk and in an unfinished handlerv2 branch, so it's unfair (imo) to
>>> think that merging fastfail to 2.3 is less work or it is safer than
>>> releasing current trunk.
>>
>>
>> I don't say that it can be backported as is. My hope (and I know that
>> I may be wrong) is that it can be backported with some work. And
>> releasing current trunk means releasing the *whole* current trunk.
>
>
> I can only repeat my vision of the current trunk:
> there are a lot of finished things applied to that tree, and only one
> thing is for sure in-progress and still subject to design analysis.
> This thing is the fastfail, that is one of the core components of
> "your" "next-minor" release.
>
> I simply think that with almost the same efforts needed to release
> 2.3+new improved fastfail (next-minor) we would release the
> "next-major" because that one is one of the few things that still
> deserve much attention.
And *this is the key point* :-) .
As an alternative approach, what would you think about not backporting
the new improved fastfail to 2.3, but instead backporting the new
filters (like spf, graylisting etc.) to the "old fastfail" availble in
2.3? Would it be simpler and safer or not?
>
> Btw I don't know the future and I can only tell you what I guess: as I
> said I don't want/need to convince anyone if everyone agree that we
> can work on this 2 versions as separated and indipendent branches.
>
> The only thing that worry me is that I want to be sure that if you
> release in hurry a new fastfail architecture in the "next-minor" we
> still mark it as experimental so we can tune it in the next-major or
> in the next-greater if needed. Nothing more than this from me.
>
>>> Furthermore I want to let you know that the new fastfail stuff need
>>> changes to configuration files and would no allow conditions (ii)
>>> and (iv), so using your numbering scheme would not be suitable for 2.4.
>>
>>
>> My point is (without integralism) to be able to get 2.4, and have my
>> production system run doing the same things as before with no or at
>> least little effort (no or very little changes to configuration) and
>> then, when I'm confortable, start exploiting the new features by
>> changing the configuration files. By little effort I mean also the
>> ability to easily rollback if weird things happen. And you know that
>> going from 2.2 to 2.3 was not simple at all!
>> *If* those things turn out to be impossible, then obviously we will
>> follow your and Norman's roadmap :-) . But *if* it is feasible, as
>> also Noel thinks, this is my choice.
>
>
> Yes, maybe this is feasible.
>
> Btw if you include config.xml and assembly.xml in your rollback you
> can do it anyway: you just need storage compatibility for this. The
> only difference is that you have an increased entry level because you
> have at least to create the new config.xml in order to use it.
>
> As I said I think that a new interim release (next-minor) is a good
> thing to james. I just wanted to put emphasys on the fact that I can't
> work on it because I spent too much on 2.3 branch (and if you remember
> at that time I said I wouldn't have worked much on the branch because
> I had to work in trunk) and if I want to keep working on James in
> future I must ensure that James keep up with the needs of my customers.
>
> I still run heavily modified local branches and my main reason for
> being a committer to james is reduce my costs to keep them updated by
> sharing my work with the community: 2.3 has been a failure in my
> roadmap, I simply can't put more efforts in a conservative release.
But probably the next-minor would be impossible to create without some
of your and Norman's help.
>
>>> I only care that this will not become a delaying issue for the
>>> release I want to work on (call it 2.4, 2.5, 3.0, TNG or reloaded,
>>> not important now).
>>
>>
>> I agree. I see work always being done on trunk, and some backporting
>> to a 2.4 branch.
>
>
> Ok!
>
>>>> To "wrap up", a final consideration: as a James user, I prefer to
>>>> have *soon* a *few* new and "safe" functionalities rather than to
>>>> wait a long time for a lot of new functionalities. But in the long
>>>> term I want James to evolve ambitiously.
>>>
>>>
>>>
>>> Well, in the last year we at least produced a release, the year
>>> before this one nothing happened.
>>> As a james user I prefer to have a release, than nothing.
>>> I don't expect our small developers community to be able to follow
>>> strict roadmaps and that's why I proposed a time based roadmap. We
>>> had a 2 years release cycle for the 2.2=>2.3 step (i've been
>>> involved only in the second year). It took one year from 2.1.3 to
>>> 2.2. So I would be happy enough if we can start producing a new
>>> release every six months: this is four times better than with 2.3
>>> and 2 times better than 2.2.
>>
>>
>> Stefano, since you came in you did a tremendous and enormous work,
>> and we all did appreciate it a lot, and we know that a very large
>> part of 2.3 is your merit. But one year ago (after a regrettable
>> delay) we were going to come out with a ("smaller") 2.3, that we were
>> then unable to finalize also because of your "vulcanic" :-)
>> activity. And I bet that if a few months ago we didn't decide to
>> converge after some arguments, 2.3 would still be "on the clouds".
>
>
> Ok, but you should also understand that we probably wouldn't have 2.3
> out if I never worked on trunk: for full months you see only "bago" in
> the svn log (for statistic funs: starting from 7 aug 2005 to 9 may
> 2006 you can find more than 200 commits and more than 90% were mine).
>
> At that time I always said: simply decide when to branch and I'll help
> with bug fixes but not with the other release issues. I did much more
> than this. I fixed our package build, updated the website, fixed the
> licesing issues and so on... I don't know why you never understood
> that it was a matter of branching. I simply didn't agree to stop
> working on trunk to let the code consolidate itself.
All true. In fact we had to "force" you somehow to help coming out with
2.3, and btw you and Norman worked much more than me also in the last
tasks for 2.3 :-) . Btw, I hope that with rc3 we are finally done!
.....
>
> I don't think that this is a generally valid approach but this time we
> are talking about few efforts and not overriding each other. I have to
> admit that if Norman was on the "next-minor" boat and against the
> "next-major" I would have thought much more before proposing to try
> following both, but I learned to work very well with Norman while I
> have much more "discussion" problems with the other PMC committers (I
> know this is a limit of mine) so the "split" thing make sense to me.
> It seems that everyone can work on what he thinks it's better: and
> opensource world works better when the project goals matches personal
> goals.
But a total split would be not good. As said above we need some help
from you and Norman for next-minor, and for example the areas where I
can mostly help are independent from the split...
.....
>
> Stefano
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map
Posted by Norman Maurer <nm...@byteaction.de>.
Vincenzo Gianferrari Pini schrieb:
> Stefano Bagnara wrote:
>
>> Vincenzo Gianferrari Pini wrote:
>>
>>>> Yes, but we already used a different scheme for 2.1, 2.2 and 2.3..
>>>> so why change it for 2.4?
>>>
>>>
>>> Because IMHO it was wrong :-) .
>>
>>
>> Ok, What I'm trying to say that consistency helps understanding: if
>> you change the rules in the middle you don't help people.
>> And if you really have to change the rule for the next minor why
>> don't we change the yet-to-be-release 2.3?
>> I simply say that imho this discussion does not belong to a 2.4.
>
> My intent is to stress that IMO, for our project, a "next minor"
> release should not be just a subset of features of a "next major"
> release, but that there are some compatibility/ease-of-install/risk
> differences from the point of view of the user, that could
> drive/justify one branching strategy or another. The numbering scheme
> is just a suggestion on how to evidentiate it, but is not the
> substance :-) .
>
>>
>>>> Anyway, I always said that I don't care about the number while
>>>> discussing, I just care about what we release and when. So we can
>>>> even talk about "the next release" and skip the number if this
>>>> helps (we'll vote the number just before the release).
>>>>
>>>> 2.x releases have been storage compatible in past, so I think we
>>>> can safely put in the 2.x scheme every future storage compatible
>>>> release and keep 3.0 for bigger steps, but mine is only a +1 vs +0,
>>>> no vetoes about this meaningless thing: we need code to make
>>>> releases, not numbers.
>>>
>>>
>>> Not only storage compatible, but also configuration compatible etc.
>>> About numbering, it is like naming: helps in stating things.
>>> And please breathe a second and take it easy before ironizing and
>>> telling other people that they say meaningless things etc. You won't
>>> convince anybody this way, you will only put them off.
>>
>>
>> This is not true: 2.x releases have been only storage compatible. I
>> had to upgrade config.xml for evey second-digit step from 2.0 to
>> 2.1.* to 2.2.0 to current 2.3.0rc3.
>
> I know. In fact I'm stressing the compatibility/ease-of-install/risk
> issue (see above) as something to take care of, for our users sake
> (*we* committers don't have too many problems of this kind).
>
>>
>> I don't say that what you say is meaningless, I say that numbering is
>> meaningless in a roadmap: a roadmap should include features, maybe
>> dates, but numbers are simply labels used to understand each other.
>
> Right. see above.
>
>>
>> So my proposal is to choose 2 names: one for the release you and Noel
>> are proposing and that will be a branch of 2.3.0 with a few features
>> from trunk to be released before the end of november and the other
>> for the release I and Norman want to work for and to be branched from
>> trunk at start of January 2007 and released in March 2007.
>>
>> I removed the (unused) 2.4 tag from our JIRA and renamed the 3.0 tag
>> to "Trunk" so that we don't introduce much more confusion. We marked
>> things resolved against 3.0, it is better to say that we resolved
>> them in trunk so we can rename trunk to something else when we'll
>> branch. My fantasy is limited so I would define then
>> "next-minor-release" and "next-major-release" (and we could have a
>> "next-greater-release" for storage incompatibility and other major
>> changes).
>>
>> I think that you can create a new version in jira and call it
>> "next-minor" and make a list of things you want to merge back in this
>> release. I hope it is fine for you if I won't work on this branch and
>> to agree that this release should not block trunk development or the
>> start of the "next-major" release.
>
> I agree. But, if the next-minor is worth doing, we all need some of
> your and Norman's help. Otherwise it probably can't be done.
I will help but only if problems raise.. I want to focus on 3.0. I only
whould help when problems accour by changes i made and you want to
backport. I have no time for doing all the merge!
>
>>
>> I'm not trying to convince anyone, and I'm simply trying to define
>> something that works for me. If you say something that I think is not
>> correct I tell you: this is the way I discuss. I think I worked much
>> more than most of other committers on the James code in the last year
>> so I think that you may not have the same visibility I had on some of
>> the code that has been included in trunk and 2.3 branch, and that's
>> why I write them here. Take into consideration that I will always
>> read and try to understand your point: this doesn't mean I change my
>> ideas easily, but I change them very often (only stupids never change
>> idea).
>
> "I perfectly know that I don't know perfectly" the new code (Socrates
> teaches ;-) ), and this is the reason why I'm now wary and
> conservative, and want to be assured and convinced by you (the one
> that knows the most about the new code) and by Noel (the one that has
> the widest knowledge of the James code in general) about how sound and
> feasible and costly and safe is to build the next-minor release (that
> we all agree that would be worth doing) from the 2.3 branch. And this
> is the kernel of the discussion going on between you and Noel, that
> I'm observing to build my final choice.
>
> And I would like to hear something from Serge, Danny and the others,
> because this is going to be a very an important decision.
>
>>
>> It's more than one year that I write to this list, you should have
>> learned that my discussion are a little rude. Don't take it so hard.
>
> Ok :-) . But we italians (especially we "emiliani" and "romagnoli")
> have sometimes to remember that we have "sangue caldo" ;-) . And the
> language doesn't help.
>
>>
>>>>> So this is how I think 2.4 should be: useful things that deserve
>>>>> and *can* be added to 2.3 in a short time frame, without too much
>>>>> work: very first among others the new fastfail (*if* the "without
>>>>> too much work" applies). "Time driven instead of feature driven"
>>>>> for minor releases.
>>>>
>>>>
>>>> If we take everything we have in trunk now and compare with 2.3 I
>>>> think that fastfail is one of the few things that cannot be
>>>> backported as is. As I already wrote we have uncomplete code both
>>>> in trunk and in an unfinished handlerv2 branch, so it's unfair
>>>> (imo) to think that merging fastfail to 2.3 is less work or it is
>>>> safer than releasing current trunk.
>>>
>>>
>>> I don't say that it can be backported as is. My hope (and I know
>>> that I may be wrong) is that it can be backported with some work.
>>> And releasing current trunk means releasing the *whole* current trunk.
>>
>>
>> I can only repeat my vision of the current trunk:
>> there are a lot of finished things applied to that tree, and only one
>> thing is for sure in-progress and still subject to design analysis.
>> This thing is the fastfail, that is one of the core components of
>> "your" "next-minor" release.
>>
>> I simply think that with almost the same efforts needed to release
>> 2.3+new improved fastfail (next-minor) we would release the
>> "next-major" because that one is one of the few things that still
>> deserve much attention.
>
> And *this is the key point* :-) .
>
> As an alternative approach, what would you think about not backporting
> the new improved fastfail to 2.3, but instead backporting the new
> filters (like spf, graylisting etc.) to the "old fastfail" availble in
> 2.3? Would it be simpler and safer or not?
>
>>
>> Btw I don't know the future and I can only tell you what I guess: as
>> I said I don't want/need to convince anyone if everyone agree that we
>> can work on this 2 versions as separated and indipendent branches.
>>
>> The only thing that worry me is that I want to be sure that if you
>> release in hurry a new fastfail architecture in the "next-minor" we
>> still mark it as experimental so we can tune it in the next-major or
>> in the next-greater if needed. Nothing more than this from me.
>>
>>>> Furthermore I want to let you know that the new fastfail stuff need
>>>> changes to configuration files and would no allow conditions (ii)
>>>> and (iv), so using your numbering scheme would not be suitable for
>>>> 2.4.
>>>
>>>
>>> My point is (without integralism) to be able to get 2.4, and have my
>>> production system run doing the same things as before with no or at
>>> least little effort (no or very little changes to configuration) and
>>> then, when I'm confortable, start exploiting the new features by
>>> changing the configuration files. By little effort I mean also the
>>> ability to easily rollback if weird things happen. And you know that
>>> going from 2.2 to 2.3 was not simple at all!
>>> *If* those things turn out to be impossible, then obviously we will
>>> follow your and Norman's roadmap :-) . But *if* it is feasible, as
>>> also Noel thinks, this is my choice.
>>
>>
>> Yes, maybe this is feasible.
>>
>> Btw if you include config.xml and assembly.xml in your rollback you
>> can do it anyway: you just need storage compatibility for this. The
>> only difference is that you have an increased entry level because you
>> have at least to create the new config.xml in order to use it.
>>
>> As I said I think that a new interim release (next-minor) is a good
>> thing to james. I just wanted to put emphasys on the fact that I
>> can't work on it because I spent too much on 2.3 branch (and if you
>> remember at that time I said I wouldn't have worked much on the
>> branch because I had to work in trunk) and if I want to keep working
>> on James in future I must ensure that James keep up with the needs of
>> my customers.
>>
>> I still run heavily modified local branches and my main reason for
>> being a committer to james is reduce my costs to keep them updated by
>> sharing my work with the community: 2.3 has been a failure in my
>> roadmap, I simply can't put more efforts in a conservative release.
>
> But probably the next-minor would be impossible to create without some
> of your and Norman's help.
See above.
>
>>
>>>> I only care that this will not become a delaying issue for the
>>>> release I want to work on (call it 2.4, 2.5, 3.0, TNG or reloaded,
>>>> not important now).
>>>
>>>
>>> I agree. I see work always being done on trunk, and some backporting
>>> to a 2.4 branch.
>>
>>
>> Ok!
>>
>>>>> To "wrap up", a final consideration: as a James user, I prefer to
>>>>> have *soon* a *few* new and "safe" functionalities rather than to
>>>>> wait a long time for a lot of new functionalities. But in the long
>>>>> term I want James to evolve ambitiously.
>>>>
>>>>
>>>>
>>>> Well, in the last year we at least produced a release, the year
>>>> before this one nothing happened.
>>>> As a james user I prefer to have a release, than nothing.
>>>> I don't expect our small developers community to be able to follow
>>>> strict roadmaps and that's why I proposed a time based roadmap. We
>>>> had a 2 years release cycle for the 2.2=>2.3 step (i've been
>>>> involved only in the second year). It took one year from 2.1.3 to
>>>> 2.2. So I would be happy enough if we can start producing a new
>>>> release every six months: this is four times better than with 2.3
>>>> and 2 times better than 2.2.
>>>
>>>
>>> Stefano, since you came in you did a tremendous and enormous work,
>>> and we all did appreciate it a lot, and we know that a very large
>>> part of 2.3 is your merit. But one year ago (after a regrettable
>>> delay) we were going to come out with a ("smaller") 2.3, that we
>>> were then unable to finalize also because of your "vulcanic" :-)
>>> activity. And I bet that if a few months ago we didn't decide to
>>> converge after some arguments, 2.3 would still be "on the clouds".
>>
>>
>> Ok, but you should also understand that we probably wouldn't have 2.3
>> out if I never worked on trunk: for full months you see only "bago"
>> in the svn log (for statistic funs: starting from 7 aug 2005 to 9 may
>> 2006 you can find more than 200 commits and more than 90% were mine).
>>
>> At that time I always said: simply decide when to branch and I'll
>> help with bug fixes but not with the other release issues. I did much
>> more than this. I fixed our package build, updated the website, fixed
>> the licesing issues and so on... I don't know why you never
>> understood that it was a matter of branching. I simply didn't agree
>> to stop working on trunk to let the code consolidate itself.
>
> All true. In fact we had to "force" you somehow to help coming out
> with 2.3, and btw you and Norman worked much more than me also in the
> last tasks for 2.3 :-) . Btw, I hope that with rc3 we are finally done!
>
> .....
I hope this too
>
>>
>> I don't think that this is a generally valid approach but this time
>> we are talking about few efforts and not overriding each other. I
>> have to admit that if Norman was on the "next-minor" boat and against
>> the "next-major" I would have thought much more before proposing to
>> try following both, but I learned to work very well with Norman while
>> I have much more "discussion" problems with the other PMC committers
>> (I know this is a limit of mine) so the "split" thing make sense to
>> me. It seems that everyone can work on what he thinks it's better:
>> and opensource world works better when the project goals matches
>> personal goals.
>
> But a total split would be not good. As said above we need some help
> from you and Norman for next-minor, and for example the areas where I
> can mostly help are independent from the split...
>
> .....
>
See above..
>>
>> Stefano
>
>
> Vincenzo
>
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> I will read and reply to the various comments later, but I want to put some
> figures into the picture.
> [..]
> $ ls -l diff.txt
> -rw-rw-r-- 1 noel noel 2056010 Sep 14 13:19 diff.txt
>
> So there are 2MB worth of differences in the Java code between trunk and
> v2.3. Some of the 2MB are overhead in the diff format, some are license
> headers, some are refactoring, some are more substantial and functional
> changes.
Ante scriptum: This 2MB things MEANS NOTHING to me (if not the RAM
leaked by your server :-P ):
a. 1MB is the header update patch (svn diff -r426006:426007
https://svn.apache.org/repos/asf/james/server/trunk/src/java
>diff-license.txt)
b. 466K are in the smtpserver package
c. Most of other changes are small refactorings (where code has been
moved in another class so it creates big diff) and new classes (we added
new mailets, and a lot of remotemanager/jmx stuff). As an example 45K of
this remaining bytes (almost 10%) are the new mailets I committed 3 days
ago: new mailets (even if they may be buggy) are much less dangerous
than the fastfail change.
That said I hope you now have a better overview of what we are talking
about and that you understand that MOST code changes are in the
smtpserver package that is the one now under branching/redesign.
> I am *not* willing to effectively accept blindly changes of roughly 15% (and
> that's only the current stuff, not including major new development) of a
> stable codebase. I *am* willing to go through it with everyone, change by
> change, and decide what is reasonably safe to add in the short term, and
> what needs much more attention for a later merger.
Why blindly? I always check what we commit in trunk: imho trunk is not
special. If you never looked at it then feel free to start reviewing it,
but the fact that you never looked at it doesn't mean that we did the
same. I don't feel blind about trunk: in fact I tried to reproduce in
trunk every single bug we found in 2.3 and I always fixed it in trunk
before checking wether the solution could be applied to the branch.
I'm not ready to start an issue by issue, commit by commit discussion
for a next-minor release.
I trust your judgement about it, so feel free to do this with Vincenzo
and anyone else that want to be part of this selection work. My reply
now would be either "let's wait, we are not ready to branch" or "+1 to
include every single patch, but we'll need to decide what to do with the
2 handlerchain trees" so it doesn't make sense that we work *together*
for this.
I hope you won't need 2 months to review the 2MB or your roadmap will
have some delay (just joking ;-) ), so feel free to review and to add
any useful consideration to this thread!
Sincerely I suggest you to finish the fastfail/handlerchain stuff before
starting this selection work as this is the bigger of the steps in your
roadmap and If I understood your roadmap fastfail is the key component
of the "next-minor" release.
I hope you will accept the "next-minor" / "next-major" proposal and that
we are ready to start.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: JAMES v2.4 Road Map
Posted by "Noel J. Bergman" <no...@devtech.com>.
I will read and reply to the various comments later, but I want to put some
figures into the picture.
$ du -hs branches/v2.3/src/java trunk/src/java
13M branches/v2.3/src/java
15M trunk/src/java
$ svn
diff --old=https://svn.apache.org/repos/asf/james/server/branches/v2.3/src/j
ava \
--new=https://svn.apache.org/repos/asf/james/server/trunk/src/ja
va >diff.txt
$ ls -l diff.txt
-rw-rw-r-- 1 noel noel 2056010 Sep 14 13:19 diff.txt
So there are 2MB worth of differences in the Java code between trunk and
v2.3. Some of the 2MB are overhead in the diff format, some are license
headers, some are refactoring, some are more substantial and functional
changes.
I am *not* willing to effectively accept blindly changes of roughly 15% (and
that's only the current stuff, not including major new development) of a
stable codebase. I *am* willing to go through it with everyone, change by
change, and decide what is reasonably safe to add in the short term, and
what needs much more attention for a later merger.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map
Posted by Stefano Bagnara <ap...@bago.org>.
Vincenzo Gianferrari Pini wrote:
>> Yes, but we already used a different scheme for 2.1, 2.2 and 2.3.. so
>> why change it for 2.4?
>
> Because IMHO it was wrong :-) .
Ok, What I'm trying to say that consistency helps understanding: if you
change the rules in the middle you don't help people.
And if you really have to change the rule for the next minor why don't
we change the yet-to-be-release 2.3?
I simply say that imho this discussion does not belong to a 2.4.
>> Anyway, I always said that I don't care about the number while
>> discussing, I just care about what we release and when. So we can even
>> talk about "the next release" and skip the number if this helps (we'll
>> vote the number just before the release).
>>
>> 2.x releases have been storage compatible in past, so I think we can
>> safely put in the 2.x scheme every future storage compatible release
>> and keep 3.0 for bigger steps, but mine is only a +1 vs +0, no vetoes
>> about this meaningless thing: we need code to make releases, not numbers.
>
> Not only storage compatible, but also configuration compatible etc.
> About numbering, it is like naming: helps in stating things.
> And please breathe a second and take it easy before ironizing and
> telling other people that they say meaningless things etc. You won't
> convince anybody this way, you will only put them off.
This is not true: 2.x releases have been only storage compatible. I had
to upgrade config.xml for evey second-digit step from 2.0 to 2.1.* to
2.2.0 to current 2.3.0rc3.
I don't say that what you say is meaningless, I say that numbering is
meaningless in a roadmap: a roadmap should include features, maybe
dates, but numbers are simply labels used to understand each other.
So my proposal is to choose 2 names: one for the release you and Noel
are proposing and that will be a branch of 2.3.0 with a few features
from trunk to be released before the end of november and the other for
the release I and Norman want to work for and to be branched from trunk
at start of January 2007 and released in March 2007.
I removed the (unused) 2.4 tag from our JIRA and renamed the 3.0 tag to
"Trunk" so that we don't introduce much more confusion. We marked things
resolved against 3.0, it is better to say that we resolved them in trunk
so we can rename trunk to something else when we'll branch. My fantasy
is limited so I would define then "next-minor-release" and
"next-major-release" (and we could have a "next-greater-release" for
storage incompatibility and other major changes).
I think that you can create a new version in jira and call it
"next-minor" and make a list of things you want to merge back in this
release. I hope it is fine for you if I won't work on this branch and to
agree that this release should not block trunk development or the start
of the "next-major" release.
I'm not trying to convince anyone, and I'm simply trying to define
something that works for me. If you say something that I think is not
correct I tell you: this is the way I discuss. I think I worked much
more than most of other committers on the James code in the last year so
I think that you may not have the same visibility I had on some of the
code that has been included in trunk and 2.3 branch, and that's why I
write them here. Take into consideration that I will always read and try
to understand your point: this doesn't mean I change my ideas easily,
but I change them very often (only stupids never change idea).
It's more than one year that I write to this list, you should have
learned that my discussion are a little rude. Don't take it so hard.
>>> So this is how I think 2.4 should be: useful things that deserve and
>>> *can* be added to 2.3 in a short time frame, without too much work:
>>> very first among others the new fastfail (*if* the "without too much
>>> work" applies). "Time driven instead of feature driven" for minor
>>> releases.
>>
>> If we take everything we have in trunk now and compare with 2.3 I
>> think that fastfail is one of the few things that cannot be backported
>> as is. As I already wrote we have uncomplete code both in trunk and in
>> an unfinished handlerv2 branch, so it's unfair (imo) to think that
>> merging fastfail to 2.3 is less work or it is safer than releasing
>> current trunk.
>
> I don't say that it can be backported as is. My hope (and I know that I
> may be wrong) is that it can be backported with some work. And releasing
> current trunk means releasing the *whole* current trunk.
I can only repeat my vision of the current trunk:
there are a lot of finished things applied to that tree, and only one
thing is for sure in-progress and still subject to design analysis. This
thing is the fastfail, that is one of the core components of "your"
"next-minor" release.
I simply think that with almost the same efforts needed to release
2.3+new improved fastfail (next-minor) we would release the "next-major"
because that one is one of the few things that still deserve much attention.
Btw I don't know the future and I can only tell you what I guess: as I
said I don't want/need to convince anyone if everyone agree that we can
work on this 2 versions as separated and indipendent branches.
The only thing that worry me is that I want to be sure that if you
release in hurry a new fastfail architecture in the "next-minor" we
still mark it as experimental so we can tune it in the next-major or in
the next-greater if needed. Nothing more than this from me.
>> Furthermore I want to let you know that the new fastfail stuff need
>> changes to configuration files and would no allow conditions (ii) and
>> (iv), so using your numbering scheme would not be suitable for 2.4.
>
> My point is (without integralism) to be able to get 2.4, and have my
> production system run doing the same things as before with no or at
> least little effort (no or very little changes to configuration) and
> then, when I'm confortable, start exploiting the new features by
> changing the configuration files. By little effort I mean also the
> ability to easily rollback if weird things happen. And you know that
> going from 2.2 to 2.3 was not simple at all!
> *If* those things turn out to be impossible, then obviously we will
> follow your and Norman's roadmap :-) . But *if* it is feasible, as also
> Noel thinks, this is my choice.
Yes, maybe this is feasible.
Btw if you include config.xml and assembly.xml in your rollback you can
do it anyway: you just need storage compatibility for this. The only
difference is that you have an increased entry level because you have at
least to create the new config.xml in order to use it.
As I said I think that a new interim release (next-minor) is a good
thing to james. I just wanted to put emphasys on the fact that I can't
work on it because I spent too much on 2.3 branch (and if you remember
at that time I said I wouldn't have worked much on the branch because I
had to work in trunk) and if I want to keep working on James in future I
must ensure that James keep up with the needs of my customers.
I still run heavily modified local branches and my main reason for being
a committer to james is reduce my costs to keep them updated by sharing
my work with the community: 2.3 has been a failure in my roadmap, I
simply can't put more efforts in a conservative release.
>> I only care that this will not become a delaying issue for the release
>> I want to work on (call it 2.4, 2.5, 3.0, TNG or reloaded, not
>> important now).
>
> I agree. I see work always being done on trunk, and some backporting to
> a 2.4 branch.
Ok!
>>> To "wrap up", a final consideration: as a James user, I prefer to
>>> have *soon* a *few* new and "safe" functionalities rather than to
>>> wait a long time for a lot of new functionalities. But in the long
>>> term I want James to evolve ambitiously.
>>
>>
>> Well, in the last year we at least produced a release, the year before
>> this one nothing happened.
>> As a james user I prefer to have a release, than nothing.
>> I don't expect our small developers community to be able to follow
>> strict roadmaps and that's why I proposed a time based roadmap. We had
>> a 2 years release cycle for the 2.2=>2.3 step (i've been involved only
>> in the second year). It took one year from 2.1.3 to 2.2. So I would be
>> happy enough if we can start producing a new release every six months:
>> this is four times better than with 2.3 and 2 times better than 2.2.
>
> Stefano, since you came in you did a tremendous and enormous work, and
> we all did appreciate it a lot, and we know that a very large part of
> 2.3 is your merit. But one year ago (after a regrettable delay) we were
> going to come out with a ("smaller") 2.3, that we were then unable to
> finalize also because of your "vulcanic" :-) activity. And I bet that
> if a few months ago we didn't decide to converge after some arguments,
> 2.3 would still be "on the clouds".
Ok, but you should also understand that we probably wouldn't have 2.3
out if I never worked on trunk: for full months you see only "bago" in
the svn log (for statistic funs: starting from 7 aug 2005 to 9 may 2006
you can find more than 200 commits and more than 90% were mine).
At that time I always said: simply decide when to branch and I'll help
with bug fixes but not with the other release issues. I did much more
than this. I fixed our package build, updated the website, fixed the
licesing issues and so on... I don't know why you never understood that
it was a matter of branching. I simply didn't agree to stop working on
trunk to let the code consolidate itself.
>> The only release I expect to come out faster is an optional bugfixing
>> 2.3.1 release that should be prepared and released *before* branching
>> the trunk for the following release (so we follow the rule to have
>> only trunk and another active branch).
>
> You see that your numbering scheme uses the third digit for bugfixing
> releases ;-) .
Yes, I agree on that :-)
I could also agree on your numbering for the second digit but I really
don't like the inconsistencies with previous releases. Imho there is no
worldwide rule for "numbering" so people have to understand the
per-project rules, but we should avoid confusions introduced by subtle
changes in internal rules (even if there were not rules and this only
have been the effect of fate).
>>> I hope all this makes sense :-) .
>>>
>>> Vincenzo
>>
>> I see that we have different ideas on the roadmap (or only on the
>> numebers?), I hope we can at least agree on the 2 working groups so
>> that we don't have to loose time discussing a roadmap that maybe no
>> one will ever be able to implement.
>
> Discussing is not losing time. I try to convince you and you try to
> convince me. You must convince me (and I'm quite open to it) that what
> my roadmap is not feasible ("no one will ever be able to implement") or
> that yours is "better", whatever it means.
Some discussion is a need, some discussion is funny but superfluos, many
discussions are only a lost of time. I feel responsible for some of them
and I'm just trying to avoid this mistake in future.
So I'm trying to skip the "you convince me", "I convince you" step and I
would like to convince ourselves that we can try working on both things
and maybe we'll merge on a single roadmap in the near or remote future.
I don't think that this is a generally valid approach but this time we
are talking about few efforts and not overriding each other. I have to
admit that if Norman was on the "next-minor" boat and against the
"next-major" I would have thought much more before proposing to try
following both, but I learned to work very well with Norman while I have
much more "discussion" problems with the other PMC committers (I know
this is a limit of mine) so the "split" thing make sense to me. It seems
that everyone can work on what he thinks it's better: and opensource
world works better when the project goals matches personal goals.
Both efforts will be a good thing to James and even if I consider the
"next-minor" not so good in term of "effort vs features" and I believe
that in 2 months here is very difficult to do anything (it took weeks
for simple test builds) I think that you will want to prove me wrong and
I will have to work harder on trunk while you are busy on the next-minor ;-)
And about the numbers I leave to you to decide when to start a vote to
change the "next-minor" and "next-major" labels to something with
numbers in it. I can already tell that I won't put vetoes, but I believe
this stuff should be decided in a vote once it's clear what is included
in each branch.
One last thing: keep in mind that if you want to make next-minor
starting from 2.3 branch and merging few stuff you will have to
relicense the code as the release will be out after 1st november and we
didn't update src headers in 2.3.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Team Work and *my* approach to open source (Was: LONG JAMES v2.4 Road Map)
Posted by Bernd Fondermann <be...@googlemail.com>.
On 9/15/06, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann wrote:
> > [...]
> > There is some truth in this. But Eclipse is driven by companies, it is
> > like a software company.
> > 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.
>
> I really agree on the whole paragrapg but the last sentence: I think
> that it is ok to use the vote as a pragmatic way to define the limits of
> our discussions.
+1, fully.
What I wanted to emphasize is: It's not only a matter of proposing and
voting _alone_.
proposal = bone
discussion = flesh
vote = skin
well, then comes development, of course...
_all_ of those taking part in the discussions are required to discuss
+ technical
+ short and on the point
+ on-topic or fork new thread
+ be consent driven
if everyone remembers those points before hitting "send", you will
see, discussion outcome will dramatically improve.
there is _so_ much noise, repetition and re-iteration going on
currently, I have trouble following.
I bet others have the same problems, too.
BTW, that also applies to the number of proposals that get started
virtually in parallel. I have noticed all, I have read some, I
understood 1 or 2, I will try to answer all of them. My apologies for
not having more time for them. Really, there is so much good stuff you
put out, I only wish I had more time. If this is causing frustration
on some part: it is not ingorance, it is the missing time.
> I don't like to discuss ages without a conclusion when
> I know we could have done both of our different ideas if we simply
> discussed less and to end up without anything done. I think I'm able to
> work in team but the team works if we agree we have advantages in
> working together.
OK, agreed, help us to keep disussions short. ;-)
> You brought us the biggest new feature in James: Unit tests.
>
> I think that your contribution, in term of code, is what is making me
> more happy to be still in James and not working on my own local branch.
Wait for the stuff I am going to contribute in future! ;-)
I, for my part, like Postage much more than the unit tests. But
obviously opinions vary.
<snip/>
> instead I preferred to work on the commons-net
> change and we have been all happy with it.
that was cool, couldn't have done that myself so quickly, many thanks again.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Team Work and *my* approach to open source (Was: LONG JAMES v2.4
Road Map)
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
> [...]
> There is some truth in this. But Eclipse is driven by companies, it is
> like a software company.
> 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.
I really agree on the whole paragrapg but the last sentence: I think
that it is ok to use the vote as a pragmatic way to define the limits of
our discussions. I don't like to discuss ages without a conclusion when
I know we could have done both of our different ideas if we simply
discussed less and to end up without anything done. I think I'm able to
work in team but the team works if we agree we have advantages in
working together.
You brought us the biggest new feature in James: Unit tests.
I think that your contribution, in term of code, is what is making me
more happy to be still in James and not working on my own local branch.
Now we have 25% unittest coverage in trunk and this is really a good
step forward if we consider that 1 year ago we had 0%! I always thought
that test was one of the biggest requirements for James but I never had
the willing to start working on it.
This is to say that often it is not the consensus or the friendship that
keep us in a group but simply a concrete reasoning: before you started
providing the unittests I worked *alone* for maybe 6 months and I also
had to fight for my ideas or even few refactorings to be accepted. I
lost much more time than I would have need to do all of this in my local
branch. In fact I still have to commit a lot of things that I developed
2 years ago in my local branch and that I never been able to commit or I
delayed because of major changes needed (ESMTP DSN support as an example
, mass remote delivery service as another example) and if it wasn't for
you and Norman I would have probably "left" the project.
I often had different ideas from you but I think we have to find
compromises if we want to take the advantages of a bigger team.
As an example your first tests used ristretto: i thought that it was not
good to james because of licensing (and maybe other I don't remember
now). I could have said "-1 to commit it, +1 if YOU replace ristretto
with commons-net" and start discussions about why using commons-net over
ristretto and so on.. instead I preferred to work on the commons-net
change and we have been all happy with it.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: LONG JAMES v2.4 Road Map
Posted by Bernd Fondermann <be...@googlemail.com>.
On 9/15/06, Jürgen Hoffmann <jh...@byteaction.de> wrote:
> Hi to all Developers,
>
> I have been following this thread for some time now. Being a Person
> that is only watching, I came to the conclusion that You as Developers
> have a totally different understanding as of what should be a 2.4
> Release.
As always, well observed ;-)
> Right now you are quarreling about things that should be defined once
> and then be clear to everyone. Looking at the Message History,
> quarreling and endless discussions are quite common to this project.
... and probably common many others here at Apache. (Some are even
worse ;-)) It is sometimes painful, but this community is not driven
by project management, it is driven by _consent_. It's not always as
pragmatic as everyone would like to have it. And there are means to
come to conclusions, mostly from shorter or longer ;-) discussions.
Votes are only the ultimate choice. This project is healthy and very
verbose in terms of communication.
Just take a second, do a quick man-power calculation and think about
how few people with very few effort (compared to other software
development) put out great software for free!
> I know I am an outsider talking, but my Company is spending a certain
> amount of time and money into this project by giving Norman the
> opportunity to support this project (the official way).
That's really great. I'd guess you get some real value back for that!
> We chose james
> because we felt that James has a good codebase, and gives us the
> opportunity to extend its functionality to what we need. We have a lot
> of Experience in E-Mail Clusters and E-Mail Product Solutions. Nothing
> was as easily extendable as james. On the Contrary, the Feature Set is
> still very limited.
>
> That said, there have been great efforts in widening this topic. Our
> Companies Goal is to make the JAMES Server a State-Of-The Art E-Mail
> Server which can be used as a drop-in solution with best-of-breed
> solutions to common problems.
>
> What we have found out is, that this project is willing to walk the
> way with us. BUT I have also found out, that the Members are hindering
> themselves to some extent by not talking objectively about certain
> topics.
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.
> Successful Open-Source Projects (Eclipse, ...) have a strict Release
> Plan (Minor Releases every 6 Months, Major Releases every Year), with a
> certain set of features. The Feature Sets should be chosen, so that the release is
> possible. The Projected Release Dates are fixed to some
> extend. If a Release Date is coming closer, and it is obvious that a
> certain feature can not be implemented/integrated to the projected
> date, there should be a vote on what to do. Move the Release Date, or
> Move the Feature to the next Release Cycle.
There is some truth in this. But Eclipse is driven by companies, it is
like a software company.
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.
> Those Rules should be clear to everyone, so noone has to argue or
> quarrel about what is a next release.
>
> 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.
>
> 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.
> So please step back from terms of throwing trunk on people and the
> like, and keep focus on the project. Clear the misunderstandings out,
> vote on release planning/cycles terminology. Keep focus on the
> project in favor of interpersonal dislikings.
I really honestly see no "personal dislikings". We are (mostly) always
on subject. What you read as dislikings are different technical
opinions and goals (which will never change) and maybe some cultural
differences. But we still are a team working together on concrete
software.
> 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".
Sorry that we aren't able to deliver more quickly, but we try to
improve. We welcome all people who'd like to contribute.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: LONG JAMES v2.4 Road Map
Posted by Stefano Bagnara <ap...@bago.org>.
Jürgen Hoffmann wrote:
> Right now you are quarreling about things that should be defined once
> and then be clear to everyone. Looking at the Message History,
> quarreling and endless discussions are quite common to this project.
Welcome to server-dev ;-)
> I see and understand that there are different understandings about
> release planning. So I want to first lay the cornerstone for the next
> release. Please vote on which mechanism you want to keep on
> developing. Vincenzo suggested the most common approach
> [...]
>>>From what I understood from the recent posts, is that release planning
> was handles different in the past, and why should one change it now,
> when it was different in the past. Well IMHO we all evolve with a
> project. Sometimes certain decisions are good, sometimes they are bad.
> But just because there have been bad decisions does not mean to keep
> bearing with them instead of changing them to something better.
So, do you think that current 2.3.0rc3 should be released as 3.0?
> But the version numbering is only solving half the problem. The next
> thing is to define what should be inside a Release. this should first
> be analyzed by topic i.e. will feature a be an incompatible change, or
> not.
I think that the version numbering is solving 5% of the problem: if we
don't write the new features we could have defined the best version
numbering scheme ever, but we would never use it.
> Successful Open-Source Projects (Eclipse, ...) have a strict Release
> Plan (Minor Releases every 6 Months, Major Releases every Year), with a
> certain set of features. The Feature Sets should be chosen, so that the release is
> possible. The Projected Release Dates are fixed to some
> extend. If a Release Date is coming closer, and it is obvious that a
> certain feature can not be implemented/integrated to the projected
> date, there should be a vote on what to do. Move the Release Date, or
> Move the Feature to the next Release Cycle.
IMO a string release plan is not in our possibilities now: we have less
than the equivalend of 2 fulltime developers working on it and not on a
regular basis (I don't know about Norman but I cannot take the
responsibility to work every day on James, I can only say I would like
to do that). Eclipse project as hundreds of developers supported by
their own companies. We could have much strict roadmaps and much more
stable releases and we would probably need a good project manager to
handle it (and not a "lazy" PMC ;-) ).
> Those Rules should be clear to everyone, so noone has to argue or
> quarrel about what is a next release.
>
> That said/written please vote about how release planning should be
> considered in the future.
>
> 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
I still don't know what Vincenzo and Noel want to do with the
"next-minor" release so I'm not able to vote now the number of their
release. We also don't have a string roadmap for "next-major" release (6
months) and I would be more inclined in using 2.x if we don't add some
more major change in current trunk, but I won't be against 3.0 or any
other number. I simply say that I'm fine with "next-minor" and
"next-major" and we can define the number as the release content is more
concrete. I think that in 3 months we'll be able to evaluate a number
for next-major, I can't say anything about next-minor until I say the
list of things that they want to backport (it seems to me that the
roadmap for this next-minor is not so defined yet)
> So please step back from terms of throwing trunk on people and the
> like, and keep focus on the project. Clear the misunderstandings out,
> vote on release planning/cycles terminology. Keep focus on the
> project in favor of interpersonal dislikings.
I want to say it again because I don't want to be misunderstood. Don't
take my ideas or my objections as trunks on people and I'm just trying
to keep the focus on the project.
I think we should use votes much more frequently and avoid endless
discussions. I already wrote a proposal for the next spf/mime4j release,
a proposal for a website change (to accomodate 2.2, 2.3 and
next-minor/next-major docs) and a proposal for the next-minor/next-major
stuff because I want to keep the focus on concrete things.
> Again I know I am an Outsider, but still I hope you consider my
> suggestions to this project
>
> Kind regards
>
> Juergen Hoffmann
One of the part I liked much more in your message is the "X and Y should
be responsible for A and Z should be responsible for B". This is really
important in project management: we cast votes, we take decisions, +1
votes should always mean active commitment toward a goal and we should
try to take responsibilities or to delegate to people we trust some of them.
As I said, I trust Vincenzo and Noel enough to know that if they work to
make a release they will do a good release so I don't need to review and
vote every single diff between trunk and 2.3 to decide what to do: I
know I may have different opinions on the risks related to a given patch
or to the importance a give feature has for our users, but I understand
that 1) I'm not the only developer, 2) this is not *my* project, 3)
other committers have enough experience to avoid big mistakes.
Stefano
PS: if it is "official" that your company support Norman in the james
work you may want to submit a Corporate CLA
(http://www.apache.org/licenses/cla-corporate.txt) as an additional
piece of paper to protect ASF from possible licensing problems.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: LONG JAMES v2.4 Road Map
Posted by Joachim Draeger <jd...@joachim-draeger.de>.
Stefano Bagnara schrieb:
> 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).
Of course I can't forecast how much time we/I can invest in IMAP the next
months, but I do hope there will be something.
But I think that it is realistic, that it won't share its API with James from
the beginning but provide Mail- or even MessageRepository wrappers for
integration. (This is how it works at the moment)
So it doesn't destabilize James or blocks releases but can be continuously
integrated and easily tried out and tested by developers/users by just
uncommenting/inserting some lines in config/assembly.xml.
Well and sometimes users find the product usable while the developer still
considers it as experimental.
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: LONG JAMES v2.4 Road Map
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
>> Do you agree with one of these 2 plans? Have you, instead, a third
>> proposal (possibly including expected date to branch/date to release and
>> expected feature list)?
>
> As I said, let's go forward with trunk. (Exception: make hotfixes to
> 2.3 and release that as 2.3.1 onward.)
> Then, at some time in the future, let's branch and release. Just like
> we did with 2.3! The date may be January. Maybe but unlikely: before
> January.
>
> Bernd
So your idea perfectly matches what me and Norman would like to do.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: LONG JAMES v2.4 Road Map
Posted by Norman Maurer <nm...@byteaction.de>.
Stefano Bagnara schrieb:
> Bernd Fondermann wrote:
>>> Do you agree with one of these 2 plans? Have you, instead, a third
>>> proposal (possibly including expected date to branch/date to release
>>> and
>>> expected feature list)?
>>
>> As I said, let's go forward with trunk. (Exception: make hotfixes to
>> 2.3 and release that as 2.3.1 onward.)
>> Then, at some time in the future, let's branch and release. Just like
>> we did with 2.3! The date may be January. Maybe but unlikely: before
>> January.
>>
>> Bernd
>
> So your idea perfectly matches what me and Norman would like to do.
>
> Stefano
Im happy to read this :-)
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: LONG JAMES v2.4 Road Map
Posted by Bernd Fondermann <be...@googlemail.com>.
On 9/15/06, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann wrote:
> > Let's at first work together on trunk and then decide to release (when
> > time is due but quite soon).
> > 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.
> > I am not opposing doing larger refactorings, or maybe even break
> > features for a limited time. But let's move forward carefully
> > nonetheless.
>
> Sorry, I think that with all this messages I'm not sure I understood
> your position.
>
> Norman and I agreed on a possible release plan for what we identified
> temporarily as "next-major":
>
> We proposed to include everything we have in current trunk + what we are
> able to implement until the beginning of January choosing from a list of
> issues we already defined (and maybe something more, discussing it). In
> January we will branch and start consolidating things to be released
> (and I expect a first alpha/beta really soon after the branch).
I am totally fine with this.
>
> Vincenzo and Noel seems to agree on branching from 2.3 and backporting
> some few selected changes to make an interim release (If I understood it
> they would not do any new development in the branch, but only
> backporting+bugfixing). They have not published the list of this few
> issues, but maybe they will do this soon.
I am OK with this, as you write it down theoretically.
My objection is: I think it is unrealistic. There would very probably
be changes on the patch branch which then would have to be
"forward-backported" (immediatly or later or never?) to trunk.
If it is only a digest of patches, that's OK.
> Do you agree with one of these 2 plans? Have you, instead, a third
> proposal (possibly including expected date to branch/date to release and
> expected feature list)?
As I said, let's go forward with trunk. (Exception: make hotfixes to
2.3 and release that as 2.3.1 onward.)
Then, at some time in the future, let's branch and release. Just like
we did with 2.3! The date may be January. Maybe but unlikely: before
January.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: LONG JAMES v2.4 Road Map
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
> Let's at first work together on trunk and then decide to release (when
> time is due but quite soon).
> 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.
> I am not opposing doing larger refactorings, or maybe even break
> features for a limited time. But let's move forward carefully
> nonetheless.
Sorry, I think that with all this messages I'm not sure I understood
your position.
Norman and I agreed on a possible release plan for what we identified
temporarily as "next-major":
We proposed to include everything we have in current trunk + what we are
able to implement until the beginning of January choosing from a list of
issues we already defined (and maybe something more, discussing it). In
January we will branch and start consolidating things to be released
(and I expect a first alpha/beta really soon after the branch).
Vincenzo and Noel seems to agree on branching from 2.3 and backporting
some few selected changes to make an interim release (If I understood it
they would not do any new development in the branch, but only
backporting+bugfixing). They have not published the list of this few
issues, but maybe they will do this soon.
Do you agree with one of these 2 plans? Have you, instead, a third
proposal (possibly including expected date to branch/date to release and
expected feature list)?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: LONG JAMES v2.4 Road Map
Posted by Bernd Fondermann <be...@googlemail.com>.
On 9/15/06, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann wrote:
> >> 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.
> 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.
> 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.
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?
(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).
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.
I am not opposing doing larger refactorings, or maybe even break
features for a limited time. But let's move forward carefully
nonetheless.
> >> 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).
Yes, seems so.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: LONG JAMES v2.4 Road Map
Posted by Bernd Fondermann <be...@googlemail.com>.
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
Re: LONG JAMES v2.4 Road Map
Posted by Jürgen Hoffmann <jh...@byteaction.de>.
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: LONG JAMES v2.4 Road Map
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
>> 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.
So I don't think at this as a project fork, but simply a consolidation
branch, like we did for 2.3. The main difference between 2.3 is that
this time I already said I can't (and want) put my efforts on the
consolidation branch. Nothing terrible at all, nothing to call home for.
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.
Imho this make sense. We can't think we'll have the efforts of every
committer for everything we decide to do. There are many James
committers that did nothing since 2.1 but they still have the power to
vote (even if they don't do this so often). As you said everyone should
be able to do what he wants (by respecting the high-level project goals)
and when he wants (and not being managed) and we should only try to
synchronize/optimize our efforts.
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.
>> 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).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: LONG JAMES v2.4 Road Map
Posted by Bernd Fondermann <be...@googlemail.com>.
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
Re: LONG JAMES v2.4 Road Map
Posted by Jürgen Hoffmann <jh...@byteaction.de>.
Hi Bernd,
Bernd Fondermann schrieb:
> ... and probably common many others here at Apache. (Some are even
> worse ;-)) It is sometimes painful, but this community is not driven
> by project management, it is driven by _consent_. It's not always as
> pragmatic as everyone would like to have it. And there are means to
> come to conclusions, mostly from shorter or longer ;-) discussions.
> Votes are only the ultimate choice. This project is healthy and very
> verbose in terms of communication.
never said it isn't. And it is good to see that the project is active. :)
> Just take a second, do a quick man-power calculation and think about
> how few people with very few effort (compared to other software
> development) put out great software for free!
I am a big fan of Apache, do not get me wrong. I am a strong believer
into open-source. And I personally know how difficult it is to support
the project next to the daily business.
>> I know I am an outsider talking, but my Company is spending a certain
>> amount of time and money into this project by giving Norman the
>> opportunity to support this project (the official way).
>
> 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.
> 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.
>> Successful Open-Source Projects (Eclipse, ...) have a strict Release
>> Plan (Minor Releases every 6 Months, Major Releases every Year), with a
>> certain set of features. The Feature Sets should be chosen, so that
>> the release is
>> possible. The Projected Release Dates are fixed to some
>> extend. If a Release Date is coming closer, and it is obvious that a
>> certain feature can not be implemented/integrated to the projected
>> date, there should be a vote on what to do. Move the Release Date, or
>> Move the Feature to the next Release Cycle.
>
> There is some truth in this. But Eclipse is driven by companies, it is
> like a software company.
driven by the community though. Take jboss for another example.
> 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.
>> 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?
>> 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.
>> So please step back from terms of throwing trunk on people and the
>> like, and keep focus on the project. Clear the misunderstandings out,
>> vote on release planning/cycles terminology. Keep focus on the
>> project in favor of interpersonal dislikings.
> I really honestly see no "personal dislikings". We are (mostly) always
> on subject. What you read as dislikings are different technical
> opinions and goals (which will never change) and maybe some cultural
> differences. But we still are a team working together on concrete
> software.
>
>> 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".
So do we/you want to deliver standards, or do you want to chase them?
> 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 ;)
Jürgen
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Version numbers (Was: LONG JAMES v2.4 Road Map)
Posted by Bernd Fondermann <be...@googlemail.com>.
On 9/16/06, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann wrote:
> > Stefano,
> >
> > Sorry, cannot parse this. You lost me way before you said that -1
> > should not be the next version number for James. I feel stupid. You
> > are using too much words for me to cope with. Do you have 3 or 4
> > simple words summarizing your ideas?
> >
> > Are you saying that, the higher the next version number will be, the
> > more substantial changes can be made? - That, I would agree upon.
>
> More easy: Let's do the changes first, we'll define the numbers later.
>
+1
(Wow, it is as easy as that?)
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Version numbers (Was: LONG JAMES v2.4 Road Map)
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
> Stefano,
>
> Sorry, cannot parse this. You lost me way before you said that -1
> should not be the next version number for James. I feel stupid. You
> are using too much words for me to cope with. Do you have 3 or 4
> simple words summarizing your ideas?
>
> Are you saying that, the higher the next version number will be, the
> more substantial changes can be made? - That, I would agree upon.
More easy: Let's do the changes first, we'll define the numbers later.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Version numbers (Was: LONG JAMES v2.4 Road Map)
Posted by Bernd Fondermann <be...@googlemail.com>.
Stefano,
Sorry, cannot parse this. You lost me way before you said that -1
should not be the next version number for James. I feel stupid. You
are using too much words for me to cope with. Do you have 3 or 4
simple words summarizing your ideas?
Are you saying that, the higher the next version number will be, the
more substantial changes can be made? - That, I would agree upon.
Bernd
On 9/15/06, Stefano Bagnara <ap...@bago.org> wrote:
> Jürgen Hoffmann wrote:
> >> I still don't know what Vincenzo and Noel want to do with the
> >> "next-minor" release so I'm not able to vote now the number of their
> >> release. We also don't have a string roadmap for "next-major" release
> >> (6 months) and I would be more inclined in using 2.x if we don't add
> >> some more major change in current trunk, but I won't be against 3.0 or
> >> any other number. I simply say that I'm fine with "next-minor" and
> >> "next-major" and we can define the number as the release content is
> >> more concrete. I think that in 3 months we'll be able to evaluate a
> >> number for next-major, I can't say anything about next-minor until I
> >> say the list of things that they want to backport (it seems to me that
> >> the roadmap for this next-minor is not so defined yet)
> > Great. So let us keep it in that way. You are fine with
> > 3.0 = Trunk
> > 2.3 = Release Branch with possible bugfix sub releases
> > 2.4 = Features that went into 3.0 which would be great to have within
> > the 2.3 application layout (This Integration Effort is do be done by the
> > 2.4 maintainers)
>
> I think the main "problem" in this discussion is that I believe that
> changes that are in trunk now and that I would like to put in the 6
> months release (next-major) are on the same line and on the same layout
> of 2.3 and they would be part of 2.3 if we didn't branch before.
>
> In fact the only common thing between 2.2 and 2.3 is that it is storage
> compatible and it didn't changed too much the mailets api (but they
> changed, and furthermore we changed the WHOLE avalon references from
> components to services). From 2.3 to trunk and to the other features we
> listed as possible candidates for inclusion there is nothing different
> from this: we'll keep it storage compatible. (I avoided committing
> storage incompatible changes because I thought to this "personal"
> roadmap few months ago).
>
> So if I was the only one to choose names I would use the 2.4 for the
> "next-minor" and 2.5 for what we defined "next-major" and delay major
> changes in the architecture for 3.0 (dsn support, container changes,
> repository changes) and I would use 2.4 for "next-major" in the case
> there was no "next-minor" release.
>
> I thought this (my idea) was clear enough, but I prefer to be clear so I
> tried to explain it one more time.
>
> I think that the numbers are appropriate from a developer perspective:
> imho the first number change has to be related to total rewrites or to
> major architectural changes included. The second number is changed when
> new features are included, the third for minor releases (tipically bug
> fixes or really small changes). I also understand the marketing
> importance of "big" version numbers, as M$ teach us, but I don't like
> James XP or James 2006 ;-) and that's why I alsways said that I prefer
> 2.3 for the current branch and not 3.0 and why I think the next should
> be consistent with that schema. And about consistency if I knew that the
> next-major will be an increment in the first number I would probably
> have preferred 3.0 for the current 2.3.0 and 4.0 for the next (this
> reflect much better what we changed).
>
> I hope I have explained enough the "why" behind my ideas and I don't
> think I need to convince anyone that my idea is better than another. In
> past PMC decided to give me the rights to vote (and I hope I deserved
> it), so I will simply vote my preference and be sure I won't use a -1
> for the version number.
>
> The only thing I care is to be able to work on my goals when I have the
> right mental state to do a good job: if we call next-major 3.0 I simply
> have more freedom on changes than what I would have if the branch is
> called 2.5 ;-) so this is enough to be happy even with a bigger number.
> Furthermore if we use a major number we can also deprecate things and
> remove some old deprecated code.
>
> So I think we should just wait for Noel, Vincenzo and anyone else that
> is willing to work for the "next-minor" release to prepare a list or
> things to be included and we can decide what the version will be (and I
> believe that if such release will be prepared we'll probably agree on
> the "2.4 branch"/2.4.0 release). About next-major we have 2-3 months
> before branching and I would like to keep storage compatibility anyway
> until that day (if possible), so we have a lot of weeks before we'll
> have to "svn copy trunk branches/vX.X" !
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Version numbers (Was: LONG JAMES v2.4 Road Map)
Posted by Stefano Bagnara <ap...@bago.org>.
Jürgen Hoffmann wrote:
>> I still don't know what Vincenzo and Noel want to do with the
>> "next-minor" release so I'm not able to vote now the number of their
>> release. We also don't have a string roadmap for "next-major" release
>> (6 months) and I would be more inclined in using 2.x if we don't add
>> some more major change in current trunk, but I won't be against 3.0 or
>> any other number. I simply say that I'm fine with "next-minor" and
>> "next-major" and we can define the number as the release content is
>> more concrete. I think that in 3 months we'll be able to evaluate a
>> number for next-major, I can't say anything about next-minor until I
>> say the list of things that they want to backport (it seems to me that
>> the roadmap for this next-minor is not so defined yet)
> Great. So let us keep it in that way. You are fine with
> 3.0 = Trunk
> 2.3 = Release Branch with possible bugfix sub releases
> 2.4 = Features that went into 3.0 which would be great to have within
> the 2.3 application layout (This Integration Effort is do be done by the
> 2.4 maintainers)
I think the main "problem" in this discussion is that I believe that
changes that are in trunk now and that I would like to put in the 6
months release (next-major) are on the same line and on the same layout
of 2.3 and they would be part of 2.3 if we didn't branch before.
In fact the only common thing between 2.2 and 2.3 is that it is storage
compatible and it didn't changed too much the mailets api (but they
changed, and furthermore we changed the WHOLE avalon references from
components to services). From 2.3 to trunk and to the other features we
listed as possible candidates for inclusion there is nothing different
from this: we'll keep it storage compatible. (I avoided committing
storage incompatible changes because I thought to this "personal"
roadmap few months ago).
So if I was the only one to choose names I would use the 2.4 for the
"next-minor" and 2.5 for what we defined "next-major" and delay major
changes in the architecture for 3.0 (dsn support, container changes,
repository changes) and I would use 2.4 for "next-major" in the case
there was no "next-minor" release.
I thought this (my idea) was clear enough, but I prefer to be clear so I
tried to explain it one more time.
I think that the numbers are appropriate from a developer perspective:
imho the first number change has to be related to total rewrites or to
major architectural changes included. The second number is changed when
new features are included, the third for minor releases (tipically bug
fixes or really small changes). I also understand the marketing
importance of "big" version numbers, as M$ teach us, but I don't like
James XP or James 2006 ;-) and that's why I alsways said that I prefer
2.3 for the current branch and not 3.0 and why I think the next should
be consistent with that schema. And about consistency if I knew that the
next-major will be an increment in the first number I would probably
have preferred 3.0 for the current 2.3.0 and 4.0 for the next (this
reflect much better what we changed).
I hope I have explained enough the "why" behind my ideas and I don't
think I need to convince anyone that my idea is better than another. In
past PMC decided to give me the rights to vote (and I hope I deserved
it), so I will simply vote my preference and be sure I won't use a -1
for the version number.
The only thing I care is to be able to work on my goals when I have the
right mental state to do a good job: if we call next-major 3.0 I simply
have more freedom on changes than what I would have if the branch is
called 2.5 ;-) so this is enough to be happy even with a bigger number.
Furthermore if we use a major number we can also deprecate things and
remove some old deprecated code.
So I think we should just wait for Noel, Vincenzo and anyone else that
is willing to work for the "next-minor" release to prepare a list or
things to be included and we can decide what the version will be (and I
believe that if such release will be prepared we'll probably agree on
the "2.4 branch"/2.4.0 release). About next-major we have 2-3 months
before branching and I would like to keep storage compatibility anyway
until that day (if possible), so we have a lot of weeks before we'll
have to "svn copy trunk branches/vX.X" !
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: LONG JAMES v2.4 Road Map
Posted by Jürgen Hoffmann <jh...@byteaction.de>.
Hi Stefano,
Stefano Bagnara schrieb:
> So, do you think that current 2.3.0rc3 should be released as 3.0?
no. what is 2.3.0rc3 is, and stays 2.3.0rc3 and will be released as
2.3.0 possible Bugs within it should be released as 2.3.1
Main development (your roadmap to 2.4) should now be 3.0 (Norman and
Stefano, ...) anything that gets into 3.0 which would be great to have
within 2.3 should go into 2.4 BUT by the 2.3/2.4 Maintainers (Noel and
Vincenzo, ...)
Did that make it clear?
> IMO a string release plan is not in our possibilities now: we have
> less than the equivalend of 2 fulltime developers working on it and
> not on a regular basis (I don't know about Norman but I cannot take
> the responsibility to work every day on James, I can only say I would
> like to do that). Eclipse project as hundreds of developers supported
> by their own companies. We could have much strict roadmaps and much
> more stable releases and we would probably need a good project manager
> to handle it (and not a "lazy" PMC ;-) ).
I see this a little dsifferent. I have been active with turbine for a
while, and they had the same sort of problems you guys have now. Today
development has stalled and the project (which is great) is short on
developers willing to contribute. Because they do not see where or with
what to help. Nobody sees the main target, or where the rpoject wants to
go to.
> I still don't know what Vincenzo and Noel want to do with the
> "next-minor" release so I'm not able to vote now the number of their
> release. We also don't have a string roadmap for "next-major" release
> (6 months) and I would be more inclined in using 2.x if we don't add
> some more major change in current trunk, but I won't be against 3.0 or
> any other number. I simply say that I'm fine with "next-minor" and
> "next-major" and we can define the number as the release content is
> more concrete. I think that in 3 months we'll be able to evaluate a
> number for next-major, I can't say anything about next-minor until I
> say the list of things that they want to backport (it seems to me that
> the roadmap for this next-minor is not so defined yet)
Great. So let us keep it in that way. You are fine with
3.0 = Trunk
2.3 = Release Branch with possible bugfix sub releases
2.4 = Features that went into 3.0 which would be great to have within
the 2.3 application layout (This Integration Effort is do be done by the
2.4 maintainers)
>> So please step back from terms of throwing trunk on people and the
>> like, and keep focus on the project. Clear the misunderstandings out,
>> vote on release planning/cycles terminology. Keep focus on the
>> project in favor of interpersonal dislikings.
>
> I want to say it again because I don't want to be misunderstood. Don't
> take my ideas or my objections as trunks on people and I'm just trying
> to keep the focus on the project.
You weren't the one i was citing ;)
> I think we should use votes much more frequently and avoid endless
> discussions. I already wrote a proposal for the next spf/mime4j
> release, a proposal for a website change (to accomodate 2.2, 2.3 and
> next-minor/next-major docs) and a proposal for the
> next-minor/next-major stuff because I want to keep the focus on
> concrete things.
agreed.
> One of the part I liked much more in your message is the "X and Y
> should be responsible for A and Z should be responsible for B". This
> is really important in project management: we cast votes, we take
> decisions, +1 votes should always mean active commitment toward a goal
> and we should try to take responsibilities or to delegate to people we
> trust some of them.
>
> As I said, I trust Vincenzo and Noel enough to know that if they work
> to make a release they will do a good release so I don't need to
> review and vote every single diff between trunk and 2.3 to decide what
> to do: I know I may have different opinions on the risks related to a
> given patch or to the importance a give feature has for our users, but
> I understand that 1) I'm not the only developer, 2) this is not *my*
> project, 3) other committers have enough experience to avoid big
> mistakes.
That would be a giant leap into the right direction.
> PS: if it is "official" that your company support Norman in the james
> work you may want to submit a Corporate CLA
> (http://www.apache.org/licenses/cla-corporate.txt) as an additional
> piece of paper to protect ASF from possible licensing problems.
If it wouldn't be official, I would have to fire him ;) I can sign this
if it is necessary. No Problem.
Jürgen Hoffmann
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: LONG JAMES v2.4 Road Map
Posted by Jürgen Hoffmann <jh...@byteaction.de>.
Hi to all Developers,
I have been following this thread for some time now. Being a Person
that is only watching, I came to the conclusion that You as Developers
have a totally different understanding as of what should be a 2.4
Release.
Right now you are quarreling about things that should be defined once
and then be clear to everyone. Looking at the Message History,
quarreling and endless discussions are quite common to this project.
I know I am an outsider talking, but my Company is spending a certain
amount of time and money into this project by giving Norman the
opportunity to support this project (the official way). We chose james
because we felt that James has a good codebase, and gives us the
opportunity to extend its functionality to what we need. We have a lot
of Experience in E-Mail Clusters and E-Mail Product Solutions. Nothing
was as easily extendable as james. On the Contrary, the Feature Set is
still very limited.
That said, there have been great efforts in widening this topic. Our
Companies Goal is to make the JAMES Server a State-Of-The Art E-Mail
Server which can be used as a drop-in solution with best-of-breed
solutions to common problems.
What we have found out is, that this project is willing to walk the
way with us. BUT I have also found out, that the Members are hindering
themselves to some extent by not talking objectively about certain
topics.
I see and understand that there are different understandings about
release planning. So I want to first lay the cornerstone for the next
release. Please vote on which mechanism you want to keep on
developing. Vincenzo suggested the most common approach
project-x.y.z releases where
x - is a release change that is not backwards compatible, or contains
major feature enhancements, that involve more inspection by the
user, because current configurations are incompatible with this
release.
y - is a release change that is backward compatible, but contains
major feature enhancements. The Installation is not guaranteed to
be working with current configurations, but most likely will.
z - is completely compatible to the previous release, and contains
only bugfixes.
From what I understood from the recent posts, is that release planning
was handles different in the past, and why should one change it now,
when it was different in the past. Well IMHO we all evolve with a
project. Sometimes certain decisions are good, sometimes they are bad.
But just because there have been bad decisions does not mean to keep
bearing with them instead of changing them to something better.
But the version numbering is only solving half the problem. The next
thing is to define what should be inside a Release. this should first
be analyzed by topic i.e. will feature a be an incompatible change, or
not.
Successful Open-Source Projects (Eclipse, ...) have a strict Release
Plan (Minor Releases every 6 Months, Major Releases every Year), with a
certain set of features. The Feature Sets should be chosen, so that the release is
possible. The Projected Release Dates are fixed to some
extend. If a Release Date is coming closer, and it is obvious that a
certain feature can not be implemented/integrated to the projected
date, there should be a vote on what to do. Move the Release Date, or
Move the Feature to the next Release Cycle.
Those Rules should be clear to everyone, so noone has to argue or
quarrel about what is a next release.
That said/written please vote about how release planning should be
considered in the future.
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
So please step back from terms of throwing trunk on people and the
like, and keep focus on the project. Clear the misunderstandings out,
vote on release planning/cycles terminology. Keep focus on the
project in favor of interpersonal dislikings.
Again I know I am an Outsider, but still I hope you consider my
suggestions to this project
Kind regards
Juergen Hoffmann
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Stefano Bagnara wrote:
> Vincenzo Gianferrari Pini wrote:
>
>> I think that we have different goals and views about what is a minor
>> release, and how it should be reflected in the naming (numbering)
>> scheme.
>>
>> For me (and as I understand also for Noel) a James x.(y+1) release
>> should be a release that (i) comes out after no more than 2-3 months
>> after an x.y release, and (ii) that can be put into production just
>> replacing the james.sar file and maybe adding/replacing/deleting some
>> lib jars, (iii) keeping storage compatibility, (iv) without any need
>> to change either config.xml, assembly.xml etc. and (v) without any
>> database schema changes (btw, IMHO point (iv) is very important).
>> James should be able to restart without problems, and changes to the
>> configuration files should be needed only to activate new
>> functionalities, and such functionalities should have been well
>> tested and "reasonably safe" and useful.
>> I know that it was not this way in the past, but I feel it should
>> have been, and should be from now on.
>
>
> Imho this is a point release definition: what I would expect in a
> 2.3.0 to 2.3.1 upgrade.
Well, I consider a "point release" a simple "bug fixing release, with no
new features", as a 2.3.1 would be (possibly not needed).
>
>> Based on this "definition", 2.3 should have been 3.0 (and what we are
>> calling 3.0 should be 4.0, but let's forget that :-) ). This
>> "numbering scheme discussion" obviously is useful only to better
>> understand each other, also in the future.
>
>
> Yes, but we already used a different scheme for 2.1, 2.2 and 2.3.. so
> why change it for 2.4?
Because IMHO it was wrong :-) .
>
> If you really want to follow this numbering we should renumber the
> current 2.3.0rc3 to 3.0.0 and not 2.3 and start working on 4.0.0, but
> as we have 3 numbers, why should we only use the first?
See above.
>
> Anyway, I always said that I don't care about the number while
> discussing, I just care about what we release and when. So we can even
> talk about "the next release" and skip the number if this helps (we'll
> vote the number just before the release).
>
> 2.x releases have been storage compatible in past, so I think we can
> safely put in the 2.x scheme every future storage compatible release
> and keep 3.0 for bigger steps, but mine is only a +1 vs +0, no vetoes
> about this meaningless thing: we need code to make releases, not numbers.
Not only storage compatible, but also configuration compatible etc.
About numbering, it is like naming: helps in stating things.
And please breathe a second and take it easy before ironizing and
telling other people that they say meaningless things etc. You won't
convince anybody this way, you will only put them off.
>
>> So this is how I think 2.4 should be: useful things that deserve and
>> *can* be added to 2.3 in a short time frame, without too much work:
>> very first among others the new fastfail (*if* the "without too much
>> work" applies). "Time driven instead of feature driven" for minor
>> releases.
>
>
> If we take everything we have in trunk now and compare with 2.3 I
> think that fastfail is one of the few things that cannot be backported
> as is. As I already wrote we have uncomplete code both in trunk and in
> an unfinished handlerv2 branch, so it's unfair (imo) to think that
> merging fastfail to 2.3 is less work or it is safer than releasing
> current trunk.
I don't say that it can be backported as is. My hope (and I know that I
may be wrong) is that it can be backported with some work. And releasing
current trunk means releasing the *whole* current trunk.
>
> Furthermore what you define "useful" is not what others may define
> "useful", so don't be so blind: I did a lot of changes for 2.3 that
> were not useful for 2.3 itself but now are the basis for the new
> developments. If I didn't include them in 2.3 we now would have much
> more code to test for the next release.
I'm saying *functionally* "useful" from a James user point of view, not
useful for *new development*. But in general you are right.
>
>> Now, how to do that? I think that the only way is through Noel's
>> approach: carefully evolve 2.3 to 2.4, adding at least (at most?) the
>> new fastfail, plus other carefully chosen things. The code from trunk
>> currently would not allow conditions (i), (ii) and (iv) above, and
>> should be used to become 3.0 following Stefano's and Norman's
>> suggested roadmap. And after 3.0, any 3.x probably should evolve from
>> 3.0, and a 4.0 would come out from trunk.
>
>
> If this is your conditions then I say let's skip 2.4 (we can't afford
> it) and work on 3.0 (see my 2.4 proposal and call it 3.0).
>
> I don't agree with this change in the numbering (why shouldn't we use
> the third number ???) but I really don't care now.. We can vote the
> preferred number the day that we'll have to release.
The point is timing: I would like to have a sound release come out in
2-3 months, while working in parallel on a major one expected to come
out in a longer time frame. And the numbering scheme just expresses that.
>
> Furthermore I want to let you know that the new fastfail stuff need
> changes to configuration files and would no allow conditions (ii) and
> (iv), so using your numbering scheme would not be suitable for 2.4.
My point is (without integralism) to be able to get 2.4, and have my
production system run doing the same things as before with no or at
least little effort (no or very little changes to configuration) and
then, when I'm confortable, start exploiting the new features by
changing the configuration files. By little effort I mean also the
ability to easily rollback if weird things happen. And you know that
going from 2.2 to 2.3 was not simple at all!
*If* those things turn out to be impossible, then obviously we will
follow your and Norman's roadmap :-) . But *if* it is feasible, as also
Noel thinks, this is my choice.
>
>
>> So, if the new fastfail is not mature enough, an effort should be put
>> on it to become so in the 2-3 months timeframe. If not possible (but
>> I don't think so), the remaining things may not be enough to justify
>> a 2.4 (unless we have bugs in 2.3 to solve that would force us to
>> build a 2.3.1: ------ 2.4 = 2.3 + bug fixes + new features ------),
>> and we would have to wait for a 3.0 coming out of trunk when we
>> decide to branch it.
>
>
> This matches what Norman and me said, but you simply want to call the
> next release 3.0 and not 2.4.
No, I'm talking about timeframe (2-3 months). If I have to wait 6+
months for 2.4 and slightly more for 3.0, it would be stupid to work on 2.4.
>
>> Who would do this 2.4 work? We know that *currently* the most active
>> committers are Stefano, Norman and (slightly less Noel), followed by
>> myself and Bernd that are both more oriented to contributions in
>> specific areas (btw more "release independent"). So Noel and Norman
>> could hopefully concentrate on fastfail and related functionalities,
>> I would work on Bayesian, Crypto (+something else that may come out)
>> , and Bernd on whatever he feels useful, appropriate and possible.
>> And Stefano can concentrate on more long term things for 3.0 and jump
>> into 2.4 when possible.
>
>
> As I already said I won't work on this 2 months timeframe release, but
> I won't be against it if you are able to work on it: I bet that in 2
> months we won't even have the first RC in your roadmap, but I would be
> happy to be wrong about this.
>
> I only care that this will not become a delaying issue for the release
> I want to work on (call it 2.4, 2.5, 3.0, TNG or reloaded, not
> important now).
I agree. I see work always being done on trunk, and some backporting to
a 2.4 branch.
>
>> To "wrap up", a final consideration: as a James user, I prefer to
>> have *soon* a *few* new and "safe" functionalities rather than to
>> wait a long time for a lot of new functionalities. But in the long
>> term I want James to evolve ambitiously.
>
>
> Well, in the last year we at least produced a release, the year before
> this one nothing happened.
> As a james user I prefer to have a release, than nothing.
> I don't expect our small developers community to be able to follow
> strict roadmaps and that's why I proposed a time based roadmap. We had
> a 2 years release cycle for the 2.2=>2.3 step (i've been involved only
> in the second year). It took one year from 2.1.3 to 2.2. So I would be
> happy enough if we can start producing a new release every six months:
> this is four times better than with 2.3 and 2 times better than 2.2.
Stefano, since you came in you did a tremendous and enormous work, and
we all did appreciate it a lot, and we know that a very large part of
2.3 is your merit. But one year ago (after a regrettable delay) we were
going to come out with a ("smaller") 2.3, that we were then unable to
finalize also because of your "vulcanic" :-) activity. And I bet that
if a few months ago we didn't decide to converge after some arguments,
2.3 would still be "on the clouds".
>
> The only release I expect to come out faster is an optional bugfixing
> 2.3.1 release that should be prepared and released *before* branching
> the trunk for the following release (so we follow the rule to have
> only trunk and another active branch).
You see that your numbering scheme uses the third digit for bugfixing
releases ;-) .
>
>> I hope all this makes sense :-) .
>>
>> Vincenzo
>
>
> I see that we have different ideas on the roadmap (or only on the
> numebers?), I hope we can at least agree on the 2 working groups so
> that we don't have to loose time discussing a roadmap that maybe no
> one will ever be able to implement.
Discussing is not losing time. I try to convince you and you try to
convince me. You must convince me (and I'm quite open to it) that what
my roadmap is not feasible ("no one will ever be able to implement") or
that yours is "better", whatever it means.
>
> Stefano
>
>
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map
Posted by Stefano Bagnara <ap...@bago.org>.
Vincenzo Gianferrari Pini wrote:
> I think that we have different goals and views about what is a minor
> release, and how it should be reflected in the naming (numbering) scheme.
>
> For me (and as I understand also for Noel) a James x.(y+1) release
> should be a release that (i) comes out after no more than 2-3 months
> after an x.y release, and (ii) that can be put into production just
> replacing the james.sar file and maybe adding/replacing/deleting some
> lib jars, (iii) keeping storage compatibility, (iv) without any need to
> change either config.xml, assembly.xml etc. and (v) without any database
> schema changes (btw, IMHO point (iv) is very important). James should be
> able to restart without problems, and changes to the configuration files
> should be needed only to activate new functionalities, and such
> functionalities should have been well tested and "reasonably safe" and
> useful.
> I know that it was not this way in the past, but I feel it should have
> been, and should be from now on.
Imho this is a point release definition: what I would expect in a 2.3.0
to 2.3.1 upgrade.
> Based on this "definition", 2.3 should have been 3.0 (and what we are
> calling 3.0 should be 4.0, but let's forget that :-) ). This "numbering
> scheme discussion" obviously is useful only to better understand each
> other, also in the future.
Yes, but we already used a different scheme for 2.1, 2.2 and 2.3.. so
why change it for 2.4?
If you really want to follow this numbering we should renumber the
current 2.3.0rc3 to 3.0.0 and not 2.3 and start working on 4.0.0, but as
we have 3 numbers, why should we only use the first?
Anyway, I always said that I don't care about the number while
discussing, I just care about what we release and when. So we can even
talk about "the next release" and skip the number if this helps (we'll
vote the number just before the release).
2.x releases have been storage compatible in past, so I think we can
safely put in the 2.x scheme every future storage compatible release and
keep 3.0 for bigger steps, but mine is only a +1 vs +0, no vetoes about
this meaningless thing: we need code to make releases, not numbers.
> So this is how I think 2.4 should be: useful things that deserve and
> *can* be added to 2.3 in a short time frame, without too much work: very
> first among others the new fastfail (*if* the "without too much work"
> applies). "Time driven instead of feature driven" for minor releases.
If we take everything we have in trunk now and compare with 2.3 I think
that fastfail is one of the few things that cannot be backported as is.
As I already wrote we have uncomplete code both in trunk and in an
unfinished handlerv2 branch, so it's unfair (imo) to think that merging
fastfail to 2.3 is less work or it is safer than releasing current trunk.
Furthermore what you define "useful" is not what others may define
"useful", so don't be so blind: I did a lot of changes for 2.3 that were
not useful for 2.3 itself but now are the basis for the new
developments. If I didn't include them in 2.3 we now would have much
more code to test for the next release.
> Now, how to do that? I think that the only way is through Noel's
> approach: carefully evolve 2.3 to 2.4, adding at least (at most?) the
> new fastfail, plus other carefully chosen things. The code from trunk
> currently would not allow conditions (i), (ii) and (iv) above, and
> should be used to become 3.0 following Stefano's and Norman's suggested
> roadmap. And after 3.0, any 3.x probably should evolve from 3.0, and a
> 4.0 would come out from trunk.
If this is your conditions then I say let's skip 2.4 (we can't afford
it) and work on 3.0 (see my 2.4 proposal and call it 3.0).
I don't agree with this change in the numbering (why shouldn't we use
the third number ???) but I really don't care now.. We can vote the
preferred number the day that we'll have to release.
Furthermore I want to let you know that the new fastfail stuff need
changes to configuration files and would no allow conditions (ii) and
(iv), so using your numbering scheme would not be suitable for 2.4.
> So, if the new fastfail is not mature enough, an effort should be put on
> it to become so in the 2-3 months timeframe. If not possible (but I
> don't think so), the remaining things may not be enough to justify a 2.4
> (unless we have bugs in 2.3 to solve that would force us to build a
> 2.3.1: ------ 2.4 = 2.3 + bug fixes + new features ------), and we would
> have to wait for a 3.0 coming out of trunk when we decide to branch it.
This matches what Norman and me said, but you simply want to call the
next release 3.0 and not 2.4.
> Who would do this 2.4 work? We know that *currently* the most active
> committers are Stefano, Norman and (slightly less Noel), followed by
> myself and Bernd that are both more oriented to contributions in
> specific areas (btw more "release independent"). So Noel and Norman
> could hopefully concentrate on fastfail and related functionalities, I
> would work on Bayesian, Crypto (+something else that may come out) , and
> Bernd on whatever he feels useful, appropriate and possible. And Stefano
> can concentrate on more long term things for 3.0 and jump into 2.4 when
> possible.
As I already said I won't work on this 2 months timeframe release, but I
won't be against it if you are able to work on it: I bet that in 2
months we won't even have the first RC in your roadmap, but I would be
happy to be wrong about this.
I only care that this will not become a delaying issue for the release I
want to work on (call it 2.4, 2.5, 3.0, TNG or reloaded, not important now).
> To "wrap up", a final consideration: as a James user, I prefer to have
> *soon* a *few* new and "safe" functionalities rather than to wait a long
> time for a lot of new functionalities. But in the long term I want James
> to evolve ambitiously.
Well, in the last year we at least produced a release, the year before
this one nothing happened.
As a james user I prefer to have a release, than nothing.
I don't expect our small developers community to be able to follow
strict roadmaps and that's why I proposed a time based roadmap. We had a
2 years release cycle for the 2.2=>2.3 step (i've been involved only in
the second year). It took one year from 2.1.3 to 2.2. So I would be
happy enough if we can start producing a new release every six months:
this is four times better than with 2.3 and 2 times better than 2.2.
The only release I expect to come out faster is an optional bugfixing
2.3.1 release that should be prepared and released *before* branching
the trunk for the following release (so we follow the rule to have only
trunk and another active branch).
> I hope all this makes sense :-) .
>
> Vincenzo
I see that we have different ideas on the roadmap (or only on the
numebers?), I hope we can at least agree on the 2 working groups so that
we don't have to loose time discussing a roadmap that maybe no one will
ever be able to implement.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
I think that we have different goals and views about what is a minor
release, and how it should be reflected in the naming (numbering) scheme.
For me (and as I understand also for Noel) a James x.(y+1) release
should be a release that (i) comes out after no more than 2-3 months
after an x.y release, and (ii) that can be put into production just
replacing the james.sar file and maybe adding/replacing/deleting some
lib jars, (iii) keeping storage compatibility, (iv) without any need to
change either config.xml, assembly.xml etc. and (v) without any database
schema changes (btw, IMHO point (iv) is very important). James should be
able to restart without problems, and changes to the configuration files
should be needed only to activate new functionalities, and such
functionalities should have been well tested and "reasonably safe" and
useful.
I know that it was not this way in the past, but I feel it should have
been, and should be from now on.
Based on this "definition", 2.3 should have been 3.0 (and what we are
calling 3.0 should be 4.0, but let's forget that :-) ). This "numbering
scheme discussion" obviously is useful only to better understand each
other, also in the future.
So this is how I think 2.4 should be: useful things that deserve and
*can* be added to 2.3 in a short time frame, without too much work: very
first among others the new fastfail (*if* the "without too much work"
applies). "Time driven instead of feature driven" for minor releases.
Now, how to do that? I think that the only way is through Noel's
approach: carefully evolve 2.3 to 2.4, adding at least (at most?) the
new fastfail, plus other carefully chosen things. The code from trunk
currently would not allow conditions (i), (ii) and (iv) above, and
should be used to become 3.0 following Stefano's and Norman's suggested
roadmap. And after 3.0, any 3.x probably should evolve from 3.0, and a
4.0 would come out from trunk.
So, if the new fastfail is not mature enough, an effort should be put on
it to become so in the 2-3 months timeframe. If not possible (but I
don't think so), the remaining things may not be enough to justify a 2.4
(unless we have bugs in 2.3 to solve that would force us to build a
2.3.1: ------ 2.4 = 2.3 + bug fixes + new features ------), and we would
have to wait for a 3.0 coming out of trunk when we decide to branch it.
Who would do this 2.4 work? We know that *currently* the most active
committers are Stefano, Norman and (slightly less Noel), followed by
myself and Bernd that are both more oriented to contributions in
specific areas (btw more "release independent"). So Noel and Norman
could hopefully concentrate on fastfail and related functionalities, I
would work on Bayesian, Crypto (+something else that may come out) , and
Bernd on whatever he feels useful, appropriate and possible. And Stefano
can concentrate on more long term things for 3.0 and jump into 2.4 when
possible.
To "wrap up", a final consideration: as a James user, I prefer to have
*soon* a *few* new and "safe" functionalities rather than to wait a long
time for a lot of new functionalities. But in the long term I want James
to evolve ambitiously.
I hope all this makes sense :-) .
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> Stefano Bagnara wrote:
>
>> Noel J. Bergman wrote:
>>> As I said long ago, if you want to move trunk to 2.4, we should
>>> review every difference. Then, if we agree that each one
>>> represents a suitable risk/reward, fine.
>
>> I'm sorry but (as I also said long ago) I'm on the opposite position
>> about the 2.4 roadmap.
>
> So what is your position? That we should simply dump trunk on users without
> proper review? Without comparing it to what we have spent so long testing
> and reviewing in the 2.3 branch?
??? I already review and test trunk, we'll start more consolidation as
soon as we'll branch: every project and every release works like this. I
never thought about a blind "tag trunk and make a final release without
even building it".
>> Now I think that not only we should include everything we have now in
>> trunk, but we should also define a period of feature development where
>> we try to put in every cool feature we are able to develop in this time
>> with one single restriction: keep storage compatibility.
>
> When do you expect to put that out?! I'm talking about a plan that allows
> us to put out a stable release very few months with carefully made changes,
> and you just want to core dump! I do not agree to that approach.
I think that we need features much more than releases. As I always said
we'll loose users if we keep making monthly releases with NO CHANGES.
>> My proposal is to start at least 2 months of free development in trunk
>> and then create the 2.4 branch to start the consolidation process.
>
> And if we do it my way, we can release 2.4 in less than 2 months. And work
> on v3 at the same time. And I want to branch soon, so that we can start
> working on the major changes that we should be doing for v3, and not just
> the safe but useful changes for v2.4.
Well, let's talk about facts: who is willing to work on your 2.4 as a
2.3 + selective branch? I won't work on it, but if you think you, and
other committers will have the time and willing to put out a 2.4 in 2
months without blocking the trunk development we can work on both
releases at the same time: 2.4 in 2 month, 2.5 in 6 months. I think that
the differences between my roadmap and the Norman roadmap can be removed
with few more discussions while your approach is not compatible.
Imo trunk is now more safe than any "2.3+selective merge" work because
both I and Norman tested trunk but no-one tested the merge work.
>> Everything we currently have in trunk deserve inclusion in the next
>> release and much more of this.
>
> Wrong. Most of what is in trunk has had a fraction of the review and
> testing that we have spent on v2.3, and you're talking about a free-for-all
> of development.
Free-for-all? I had flame wars for a "fetchmail refactoring" and you
talk of free-for-all??
>> Furthermore I would consider a big mistake to try to release 2.4 as a
>> 2.3 + new fastfail things, because new fastfail things are still in
>> progress and not mature enough
>
> And yet you want to use TRUNK as 2.4?! Be consistent. Trunk has many such
> "still in progress and not mature enough" things, not just fast-fail. Maybe
> we decide that fast-fail isn't mature enough yet. As you say:
Yes, I think that now fastfail is not mature, but working on it for 2-3
more months we can find a good solution: we were simply too busy on 2.3
to work on fastfail stabilization. Many new things have been written in
the fastfail package and I still have to test them.
Your 2 months roadmap is simply not concrete to me: we need weeks to
simply vote an alpha release and you think you can produce a new final
in 2 months? Imo if you start a selective work you will need 2 months
only to discuss what to include and what to exclude... btw as I said
before I don't think I need to convince you, we can simply try. If you
can manage a 2.4 release that will not block us from working on the 3
months development/3 months consolidation work I can leave with it.
>> There is a lot of stuff that has been removed by the 2.3 branch but
>> should really fit the 2.4 branch: database read/write streaming (we have
>> write streaming in 2.3 but disabled by default because we had no time to
>> test it enough), spool manager refactorings, 8bitmime (try again with
>> new javamail fixes). We should refactor pop3 to follow the same smtp
>> handlerchain pattern (and maybe do the same for remotemanager and nntp).
>> We could try to include easier virtualhosting support, support for APOP
>> and much other features that don't introduce storage incompatibility
>> problems.
>
> Not all of those share the same level of testing, value or urgency, and yet
> you just want to dump it all on users as if we had carefully developed and
> tested them?
It would take months of discussion to decide what deserve inclusion and
what not. Imo 2.4 can't be "your own needs release", but if you are able
to work on it, test it, document it, and publish it in 2 months then I
won't stop you from doing this: a new stable release is for sure good to
James. That said I can't simply spend more time consolidating a product
that I won't use so I have to keep my feet on trunk for a while,
including features and changes I plan since I started working on James.
2.3 took to much of my time and delayed trunk development too much.
> You've just ennumerated a whole raft of issues. We should examine each one
> to decide if THAT SPECIFIC PIECE is stable enough to go into the release,
> not conflate a dozen or more items.
Maybe you want to go ahead and make the exact list of what you need in
2.4. I already did it: ALL + the "whole raft of issues".
> So we can start with ones that we all agree ARE stable enough to go into
> v2.4, and not just dump a load of immature code on top of our stable
> release.
I believe we will have different opinions on what is stable and what is
not. In 2 months we'll probably find out that we have different lists
;-). This is why I think we can skip the whole discussion and talk about
who is willing to work on what: I now need to work on trunk for new
features and to finish at least a few things I started there and I'm
willing to work on new features only. In few months I will be ready
again to do some more testing and consolidation work.
>> A last reason to not start a 2.4 branch now and to not start a selective
>> merge job is that we are not sure that 2.3.0 would not need a 2.3.1
>> release in a month
>
> If we start v2.4 from v2.3, we don't need 2.3.1. 2.4 would be suffice. I
> want to start using this stuff ASAP, not after another year of development
> and testing.
>
> --- Noel
Sorry but I don't believe that 2.4 will be out in 2 months and if we
find critical bugs in 2.3 then we will need a 2.3.1 as soon as possible.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map
Posted by Bernd Fondermann <be...@googlemail.com>.
On 9/15/06, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann wrote:
> >> For me its:
> >> 2.3.x = bugfixes
> >> 2.4 = 2.3.x + new features ( compatible)
> >> 3.0 = incompatible changes
> >
> > addition: 3.0 = incompatible changes, big new features
> >
> > +1, thats absolutely my take, and my understanding about what is
> > common sense in the industry
> > And I don't think its only a number. It is a means of communication to
> > the user base.
> >
> > Bernd
>
> When I say that "it is only a number" and I don't care of the "number" I
> mean *NOW* that we are planning a ROADMAP I don't care too much of the
> numbers. I agree that the number is really important for a release but I
> think we could simply decide the right number for our marketing purposes
> just before releasing it. Either way we need a way to talk each others
> about the different roadmaps/branches, so I thought at the "next-minor",
> "next-major" labels... I'm trying to reduce the number of things to be
> discussed now to the minimum so to increase the probability that we come
> to some agreement on what to do.
>
> If anyone want to start a proposal for a new numbering, I suggest to do
> it as a separated thread, and I will add my ideas and I will vote about
> it. I already said that I'm not against the numbering proposed by
> Vincenzo (or your), and we discussed few times about the current 2.3 in
> terms of 3.0: we finally decided to use the 2.3 number. I think we
> should have no worry to make proposals and cast our votes. You know I
> really used few -1 in past, so don't think that every time I have a
> different idea it means I will veto it. I usually say "I would probably
> veto this" if I think I will do that and when I say "I don't agree / I
> have a different idea" it means that I will probably vote -0 and propose
> something alternative.
ok, sure, fine. what's the point?
> I don't start that proposal now because I already
> wrote 2 proposals that are awaiting answers or actions by the people
> with karma so I don't want to put too many things in the in-progress list.
trying to get through to it, but you are writing _lots_ of text, man!
that's really eating up my time.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
>> For me its:
>> 2.3.x = bugfixes
>> 2.4 = 2.3.x + new features ( compatible)
>> 3.0 = incompatible changes
>
> addition: 3.0 = incompatible changes, big new features
>
> +1, thats absolutely my take, and my understanding about what is
> common sense in the industry
> And I don't think its only a number. It is a means of communication to
> the user base.
>
> Bernd
When I say that "it is only a number" and I don't care of the "number" I
mean *NOW* that we are planning a ROADMAP I don't care too much of the
numbers. I agree that the number is really important for a release but I
think we could simply decide the right number for our marketing purposes
just before releasing it. Either way we need a way to talk each others
about the different roadmaps/branches, so I thought at the "next-minor",
"next-major" labels... I'm trying to reduce the number of things to be
discussed now to the minimum so to increase the probability that we come
to some agreement on what to do.
If anyone want to start a proposal for a new numbering, I suggest to do
it as a separated thread, and I will add my ideas and I will vote about
it. I already said that I'm not against the numbering proposed by
Vincenzo (or your), and we discussed few times about the current 2.3 in
terms of 3.0: we finally decided to use the 2.3 number. I think we
should have no worry to make proposals and cast our votes. You know I
really used few -1 in past, so don't think that every time I have a
different idea it means I will veto it. I usually say "I would probably
veto this" if I think I will do that and when I say "I don't agree / I
have a different idea" it means that I will probably vote -0 and propose
something alternative. I don't start that proposal now because I already
wrote 2 proposals that are awaiting answers or actions by the people
with karma so I don't want to put too many things in the in-progress list.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map
Posted by Bernd Fondermann <be...@googlemail.com>.
On 9/14/06, Norman Maurer <nm...@byteaction.de> wrote:
> Vincenzo Gianferrari Pini schrieb:
> > I think that we have different goals and views about what is a minor
> > release, and how it should be reflected in the naming (numbering) scheme.
> >
> > For me (and as I understand also for Noel) a James x.(y+1) release
> > should be a release that (i) comes out after no more than 2-3 months
> > after an x.y release, and (ii) that can be put into production just
> > replacing the james.sar file and maybe adding/replacing/deleting some
> > lib jars, (iii) keeping storage compatibility, (iv) without any need
> > to change either config.xml, assembly.xml etc. and (v) without any
> > database schema changes (btw, IMHO point (iv) is very important).
> > James should be able to restart without problems, and changes to the
> > configuration files should be needed only to activate new
> > functionalities, and such functionalities should have been well tested
> > and "reasonably safe" and useful.
> > I know that it was not this way in the past, but I feel it should have
> > been, and should be from now on.
> >
> > Based on this "definition", 2.3 should have been 3.0 (and what we are
> > calling 3.0 should be 4.0, but let's forget that :-) ). This
> > "numbering scheme discussion" obviously is useful only to better
> > understand each other, also in the future.
> >
> > So this is how I think 2.4 should be: useful things that deserve and
> > *can* be added to 2.3 in a short time frame, without too much work:
> > very first among others the new fastfail (*if* the "without too much
> > work" applies). "Time driven instead of feature driven" for minor
> > releases.
> >
> > Now, how to do that? I think that the only way is through Noel's
> > approach: carefully evolve 2.3 to 2.4, adding at least (at most?) the
> > new fastfail, plus other carefully chosen things. The code from trunk
> > currently would not allow conditions (i), (ii) and (iv) above, and
> > should be used to become 3.0 following Stefano's and Norman's
> > suggested roadmap. And after 3.0, any 3.x probably should evolve from
> > 3.0, and a 4.0 would come out from trunk.
> Who will do this merge and test it ? I don't think it will be more
> stable then the code in trunk. For me that make no sense.. Then we have
> to maintain 3 trees. We are to few developer for that.
I share Norman's objections. Maintaining 3 trees will not help us
progressing, it will only help stalling the project.
> For me its:
> 2.3.x = bugfixes
> 2.4 = 2.3.x + new features ( compatible)
> 3.0 = incompatible changes
addition: 3.0 = incompatible changes, big new features
+1, thats absolutely my take, and my understanding about what is
common sense in the industry
And I don't think its only a number. It is a means of communication to
the user base.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map
Posted by Norman Maurer <nm...@byteaction.de>.
Vincenzo Gianferrari Pini schrieb:
> I think that we have different goals and views about what is a minor
> release, and how it should be reflected in the naming (numbering) scheme.
>
> For me (and as I understand also for Noel) a James x.(y+1) release
> should be a release that (i) comes out after no more than 2-3 months
> after an x.y release, and (ii) that can be put into production just
> replacing the james.sar file and maybe adding/replacing/deleting some
> lib jars, (iii) keeping storage compatibility, (iv) without any need
> to change either config.xml, assembly.xml etc. and (v) without any
> database schema changes (btw, IMHO point (iv) is very important).
> James should be able to restart without problems, and changes to the
> configuration files should be needed only to activate new
> functionalities, and such functionalities should have been well tested
> and "reasonably safe" and useful.
> I know that it was not this way in the past, but I feel it should have
> been, and should be from now on.
>
> Based on this "definition", 2.3 should have been 3.0 (and what we are
> calling 3.0 should be 4.0, but let's forget that :-) ). This
> "numbering scheme discussion" obviously is useful only to better
> understand each other, also in the future.
>
> So this is how I think 2.4 should be: useful things that deserve and
> *can* be added to 2.3 in a short time frame, without too much work:
> very first among others the new fastfail (*if* the "without too much
> work" applies). "Time driven instead of feature driven" for minor
> releases.
>
> Now, how to do that? I think that the only way is through Noel's
> approach: carefully evolve 2.3 to 2.4, adding at least (at most?) the
> new fastfail, plus other carefully chosen things. The code from trunk
> currently would not allow conditions (i), (ii) and (iv) above, and
> should be used to become 3.0 following Stefano's and Norman's
> suggested roadmap. And after 3.0, any 3.x probably should evolve from
> 3.0, and a 4.0 would come out from trunk.
Who will do this merge and test it ? I don't think it will be more
stable then the code in trunk. For me that make no sense.. Then we have
to maintain 3 trees. We are to few developer for that. I also see no
problems with i - v. If you look at Stefanos list of things todo for 2.4
you will notice that this things will not require such changes. Only for
new features like you said..
I think we can do most of the changes in about 6 Month. So a new
"powerfull release" in 6 Month is cool... So why loose time with
mergin.. it will take weeks .
>
> So, if the new fastfail is not mature enough, an effort should be put
> on it to become so in the 2-3 months timeframe. If not possible (but I
> don't think so), the remaining things may not be enough to justify a
> 2.4 (unless we have bugs in 2.3 to solve that would force us to build
> a 2.3.1: ------ 2.4 = 2.3 + bug fixes + new features ------), and we
> would have to wait for a 3.0 coming out of trunk when we decide to
> branch it.
For me its:
2.3.x = bugfixes
2.4 = 2.3.x + new features ( compatible)
3.0 = incompatible changes
>
> Who would do this 2.4 work? We know that *currently* the most active
> committers are Stefano, Norman and (slightly less Noel), followed by
> myself and Bernd that are both more oriented to contributions in
> specific areas (btw more "release independent"). So Noel and Norman
> could hopefully concentrate on fastfail and related functionalities, I
> would work on Bayesian, Crypto (+something else that may come out) ,
> and Bernd on whatever he feels useful, appropriate and possible. And
> Stefano can concentrate on more long term things for 3.0 and jump into
> 2.4 when possible.
>
> To "wrap up", a final consideration: as a James user, I prefer to have
> *soon* a *few* new and "safe" functionalities rather than to wait a
> long time for a lot of new functionalities. But in the long term I
> want James to evolve ambitiously.
>
> I hope all this makes sense :-) .
>
> Vincenzo
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: JAMES v2.4 Road Map
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> Noel J. Bergman wrote:
> > As I said long ago, if you want to move trunk to 2.4, we should
> > review every difference. Then, if we agree that each one
> > represents a suitable risk/reward, fine.
> I'm sorry but (as I also said long ago) I'm on the opposite position
> about the 2.4 roadmap.
So what is your position? That we should simply dump trunk on users without
proper review? Without comparing it to what we have spent so long testing
and reviewing in the 2.3 branch?
> We've just finished with a lot of efforts to put out a stable release to
> replace the old 2.2.0.
Exactly.
> Now I think that not only we should include everything we have now in
> trunk, but we should also define a period of feature development where
> we try to put in every cool feature we are able to develop in this time
> with one single restriction: keep storage compatibility.
When do you expect to put that out?! I'm talking about a plan that allows
us to put out a stable release very few months with carefully made changes,
and you just want to core dump! I do not agree to that approach.
> My proposal is to start at least 2 months of free development in trunk
> and then create the 2.4 branch to start the consolidation process.
And if we do it my way, we can release 2.4 in less than 2 months. And work
on v3 at the same time. And I want to branch soon, so that we can start
working on the major changes that we should be doing for v3, and not just
the safe but useful changes for v2.4.
> Everything we currently have in trunk deserve inclusion in the next
> release and much more of this.
Wrong. Most of what is in trunk has had a fraction of the review and
testing that we have spent on v2.3, and you're talking about a free-for-all
of development.
> Furthermore I would consider a big mistake to try to release 2.4 as a
> 2.3 + new fastfail things, because new fastfail things are still in
> progress and not mature enough
And yet you want to use TRUNK as 2.4?! Be consistent. Trunk has many such
"still in progress and not mature enough" things, not just fast-fail. Maybe
we decide that fast-fail isn't mature enough yet. As you say:
> There is a lot of stuff that has been removed by the 2.3 branch but
> should really fit the 2.4 branch: database read/write streaming (we have
> write streaming in 2.3 but disabled by default because we had no time to
> test it enough), spool manager refactorings, 8bitmime (try again with
> new javamail fixes). We should refactor pop3 to follow the same smtp
> handlerchain pattern (and maybe do the same for remotemanager and nntp).
> We could try to include easier virtualhosting support, support for APOP
> and much other features that don't introduce storage incompatibility
> problems.
Not all of those share the same level of testing, value or urgency, and yet
you just want to dump it all on users as if we had carefully developed and
tested them?
You've just ennumerated a whole raft of issues. We should examine each one
to decide if THAT SPECIFIC PIECE is stable enough to go into the release,
not conflate a dozen or more items.
So we can start with ones that we all agree ARE stable enough to go into
v2.4, and not just dump a load of immature code on top of our stable
release.
> A last reason to not start a 2.4 branch now and to not start a selective
> merge job is that we are not sure that 2.3.0 would not need a 2.3.1
> release in a month
If we start v2.4 from v2.3, we don't need 2.3.1. 2.4 would be suffice. I
want to start using this stuff ASAP, not after another year of development
and testing.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v2.4 Road Map
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> Norman Maurer wrote:
>
>>>> Personally, I'm ready to make it a release, and start work on 2.4,
> which
>>>> should be a careful selection of things to add, not a core dump from
> trunk.
>>> We never agreed on this roadmap. And I think I won't agree on this
>>> approach even later.
>> I agree with Stefano. For me we should use the current trunk as 2.4
>> ( with handler-api2 merged when its complete). I don't see any
>> problems with it. We don't did "critical" changes which whould break
>> compatibly.
>
> It should still be a careful selection. As I said long ago, if you want to
> move trunk to 2.4, we should review every difference. Then, if we agree
> that each one represents a suitable risk/reward, fine.
I'm sorry but (as I also said long ago) I'm on the opposite position
about the 2.4 roadmap.
We've just finished with a lot of efforts to put out a stable release to
replace the old 2.2.0. 2.3.0 didn't introduce so much changes, but
included a lot of fixes and a lot of refactoring useful for future
improvements.
Now I think that not only we should include everything we have now in
trunk, but we should also define a period of feature development where
we try to put in every cool feature we are able to develop in this time
with one single restriction: keep storage compatibility.
We kept storage compatibility between 2.2.0 and 2.3.0 and imho we can do
the same for 2.3.0 to 2.4.0. config.xml will change, assembly.xml will
change, maybe a few minor methods in the mailet apis could change.
My proposal is to start at least 2 months of free development in trunk
and then create the 2.4 branch to start the consolidation process.
Considering that 2 months would be just before Christmas I would say let
's develop new features in trunk including the whole Christmas and we'll
branch on the first days of 2007.
Everything we currently have in trunk deserve inclusion in the next
release and much more of this. We worked hard on 2.3 and I'm not ready
and I'm not willing to start a new consolidation work just now.
We have to look the long term also: I don't care if some of the feature
we implemented in trunk will not be used by 2.4, I care that we use the
next release also to consolidate that code so we'll be much more ready
for 2.5 or 3.0.
Furthermore I would consider a big mistake to try to release 2.4 as a
2.3 + new fastfail things, because new fastfail things are still in
progress and not mature enough (we still have an incomplete branch with
a fastfail-v2 attempt). I don't want to make another release where
fastfail is again marked as "experimental" because we're still working
on it.
There is a lot of stuff that has been removed by the 2.3 branch but
should really fit the 2.4 branch: database read/write streaming (we have
write streaming in 2.3 but disabled by default because we had no time to
test it enough), spool manager refactorings, 8bitmime (try again with
new javamail fixes). We should refactor pop3 to follow the same smtp
handlerchain pattern (and maybe do the same for remotemanager and nntp).
We could try to include easier virtualhosting support, support for APOP
and much other features that don't introduce storage incompatibility
problems.
Another thing is that we should wait for dnsjava 2.0.3 to include full
SPF support and we should wait for javamail 1.4.1 to try to enable
8bitmime stuff again.
A last reason to not start a 2.4 branch now and to not start a selective
merge job is that we are not sure that 2.3.0 would not need a 2.3.1
release in a month and we should really avoid having 3 open branches
(2.3, 2.4, trunk).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org