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