Noel J. Bergman wrote:
Stefano Bagnara wrote:
Well, I believe in you, but I also know that you are the only supporter
of the "next-minor"
Actually not, but I believe that you've talked most people to death on it.
That doesn't work on me.
This is a major issue. No one voted something different than +0 to the
next-minor vote. I believe I didn't write false statement and that the
vote was fair. If you think this is not true please start a vote NOW.
Please do it or accept that you are the only active supporter of that
release: there is nothing wrong in being alone acrively supporting a
release, I did it for 1 year.
Please don't tell me that I should not discuss now: you all asked me to
discuss much more when I was committing. If I can't discuss and I can't
commit maybe I should better leave the project ;-)
and you are so busy that you have to vote on the "James Server future
releases/road maps" vote I started in October the 25th.
Actually, I just prioritize my time. First, I was at a conference, and then
I was fixing fictional bugs because my production server shared my
delusions.
This is what everyone do: I lost money in the last year to fix bugs in
james 2.3.0, most time bugs on code I didn't write. I could have skipped
bug fixes to work on new features, but this sentences seems to me a bit
off-topic.
So I think it is safer for the project if we keep open the way to
a 2.3.1 in case you'll be busier than you think now and we have to
cancel next-minor.
My time to waste.
?
I can offer myself ot mantain 2.3.1, so it will not be more time for
you. And if you know what you are doing on next-minor I bet you won't
waste your time.
Being alone on that branch make you almost the only responsible people
for his own time: if you'll succeed with the next-minor featureset (you
for sure understand that is not clear what will be included there) and
its release dates everyone here will be happy and your time won't be wasted.
The doubts you later expose about "next-major" are the same doubts I
have about your next-minor: I understood you want handlerapi-v2 in
"next-minor"
In the first out? I doubt it. Ever? That would all depend on just how bad
the code is that comes over from trunk.
This is a news! I'm happy to be updated on this. In the "JAMES 2.4 Road
Map" thread you and Vincenzo wrote that handler api changes would have
been part of the minor release you were proposing (with commons-daemon
and few other features).
I would like to see less discussions like this one and more pratical
discussions on code/issues to be included in each release, commitment
and collaboration.
I will be really happy if you do [the handlerapi-v2], because it is
the bigger missing piece for next-major.
That and the scheduler/spooler changes. I was going to work on the handler
this week, but ended up fixing the other two bugs instead. But as soon as I
finish packing and invoicing, back to the handler API. :-)
Are scheduler/spooler changes you planned "config.xml compatible"?
I remember your "starting" proposal and it was not compatible. If you
can do it compatible it would be a great feature!
I think timeframe is a key part of the next-major release, and we'll
probably postpone some of the feature expected to be in next-major
if they are not ready for the estimated branch time.
It is not a matter of features. If you really want to have a stable release
anytime in early 2007, we're going to have to get serious, compare v2.3.0
with trunk, branch trunk with largely the same code that is in v2.3.0 except
for known and reviewed improvements, and go from there. Some of us are
going to have to review changes --- line for line --- between the stable
code and whatever we copy from trunk. Until then, I'm just going to view
trunk as an unstable dumping ground.
Well, you're free to have your own view on what is stable and what is
not, and how much time is going to take to consolidate some code, and I
can't try to convince you, but you have to understand that your view
could also be wrong.
I and Norman already do this review work day by day, and I guess we have
more eyes on trunk now than we had in the last year on the 2.3 branch.
I feel current trunk is much more stable than trunk when we branched
2.3. Even more, I feel it is more stable that 2.3.0b1.
The most important fact is that a lot of code changed, but we had no
critical changes on the core, that we instead had in 2.3.0 (mimemessage
copyonwrite proxy, repository locks management and similar).
"next-major" had a lot of supporter in the vote I discussed above, so I
expect a lot of effort to make that real in the estimated timeframe.
Actually, no. What people said was that they figured that you'd be doing
it. Re-read the e-mails.
Sorry but I read it again 5 times, in the vote I started I never wrote I
would have done something. If you can correct my english interpretation
please help me, because I tried to be as clear as possible.
For example, I would not expect to see the refactored Mailet API in a
production release anytime soon.
--- Noel
Nor do I. And they are not in trunk. And I would currently veto the
inclusion in trunk. And I understood from Danny that his work is an
experiment to have a strawman implementation to better discuss the next
mailet apis (I asked Danny which version he's targetting but he never
replied, but I guess he target next-greater and not next-major).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
