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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
