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