james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer ...@byteaction.de>
Subject Re: Next 2.x release
Date Mon, 06 Nov 2006 08:14:22 GMT
Noel J. Bergman schrieb:
> 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.
>   
Please guys.. not again !

>   
>> 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.
>
>   
>> 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 whould follow Stefano..

>> 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.
>   
Please.. Stop saying trunk code is bad... It isn'T. If you really  think
its bad you should give us more infos which code you think is bad.. Or
better fix it directly
>   
>> 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.  :-)
>   
I hope you finish it soon :-)
>   
>> 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.
>   
Read my comment above.. I really not agree with you. Trunk is not such
unstable as you told us everytime. And i really believe its at least
such stable as 2.2.0 !

>   
>> "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.
>
> For example, I would not expect to see the refactored Mailet API in a
> production release anytime soon.
>
> 	--- Noel

bye
Norman



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message