james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer ...@byteaction.de>
Subject RE: JAMES v2.4 Road Map
Date Wed, 13 Sep 2006 05:55:12 GMT
Am Dienstag, den 12.09.2006, 21:44 -0400 schrieb Noel J. Bergman:
> Stefano Bagnara wrote:
> 
> > Noel J. Bergman wrote:
> > > As I said long ago, if you want to move trunk to 2.4, we should
> > > review every difference.  Then, if we agree that each one
> > > represents a suitable risk/reward, fine.
> 
> > I'm sorry but (as I also said long ago) I'm on the opposite position
> > about the 2.4 roadmap.
> 
> So what is your position?  That we should simply dump trunk on users without
> proper review?  Without comparing it to what we have spent so long testing
> and reviewing in the 2.3 branch?
Well we should start testing the trunk ;-) (I have trunk running
allready on a testserver) So we can get sure its stable and fix bugs!

> 
> > We've just finished with a lot of efforts to put out a stable release to
> > replace the old 2.2.0.
> 
> Exactly.
And it seems that is do a much better job. I agree.

> 
> > Now I think that not only we should include everything we have now in
> > trunk, but we should also define a period of feature development where
> > we try to put in every cool feature we are able to develop in this time
> > with one single restriction: keep storage compatibility.
> 
> When do you expect to put that out?!  I'm talking about a plan that allows
> us to put out a stable release very few months with carefully made changes,
> and you just want to core dump!  I do not agree to that approach.
I don't agree with you both :-P 
I think we need a roadmap and only workin on the code which include
features which listed in the roadmap. Bugs should be fixed too.. 
When someone feel to work on a other task then one listed in the roadmap
he should raise his voice in the mailinglist and if we agree we put it
on the roadmap and include it. If not he should wait with the work and
wait for next release.
Like i said before i see no problems starting to workin on 2.4 and use
trunk as it is. I whould be happy if we could put out 2.4 in about 6
Month later then 2.3 is released. 
   
> 
> > My proposal is to start at least 2 months of free development in trunk
> > and then create the 2.4 branch to start the consolidation process.
> 
> And if we do it my way, we can release 2.4 in less than 2 months.  And work
> on v3 at the same time.  And I want to branch soon, so that we can start
> working on the major changes that we should be doing for v3, and not just
> the safe but useful changes for v2.4.

See my comment above. 

> 
> > Everything we currently have in trunk deserve inclusion in the next
> > release and much more of this.
> 
> Wrong.  Most of what is in trunk has had a fraction of the review and
> testing that we have spent on v2.3, and you're talking about a free-for-all
> of development.
See my comment above.. We need a roadmap.

> 
> > Furthermore I would consider a big mistake to try to release 2.4 as a
> > 2.3 + new fastfail things, because new fastfail things are still in
> > progress and not mature enough
> 
> And yet you want to use TRUNK as 2.4?!  Be consistent.  Trunk has many such
> "still in progress and not mature enough" things, not just fast-fail.  Maybe
> we decide that fast-fail isn't mature enough yet.  As you say:

I agree that we have stuff which is not 100% finish. So we need to focus
on that first! The handler api is one of the stuff we need to finish
first soon. Cause as longer we wait as harder it get to merge the
stuff. 

> 
> > There is a lot of stuff that has been removed by the 2.3 branch but
> > should really fit the 2.4 branch: database read/write streaming (we have
> > write streaming in 2.3 but disabled by default because we had no time to
> > test it enough), spool manager refactorings, 8bitmime (try again with
> > new javamail fixes). We should refactor pop3 to follow the same smtp
> > handlerchain pattern (and maybe do the same for remotemanager and nntp).
> > We could try to include easier virtualhosting support, support for APOP
> > and much other features that don't introduce storage incompatibility
> > problems.
> 
> Not all of those share the same level of testing, value or urgency, and yet
> you just want to dump it all on users as if we had carefully developed and
> tested them?
Thats why we should try to test it again. It will never get stable if
noone tests. Please don't let us do the same mistake as in 2.3... We all
need to test it more. I have always a "trunk server" on a testsystem
which serve some not so importent stuff.
 
> 
> You've just ennumerated a whole raft of issues.  We should examine each one
> to decide if THAT SPECIFIC PIECE is stable enough to go into the release,
> not conflate a dozen or more items.
> 
> So we can start with ones that we all agree ARE stable enough to go into
> v2.4, and not just dump a load of immature code on top of our stable
> release.

See other comments.

> 
> > A last reason to not start a 2.4 branch now and to not start a selective
> > merge job is that we are not sure that 2.3.0 would not need a 2.3.1
> > release in a month
> 
> If we start v2.4 from v2.3, we don't need 2.3.1.  2.4 would be suffice.  I
> want to start using this stuff ASAP, not after another year of development
> and testing.
> 	--- Noel
> 
> 
I agree with Stefano.. And i think we can push a 2.4 release in 6 Month
( At least i hope so). 

So i think the next step must a roadmap! First we should dedicide which
jira issues should be moved to 2.4 before do anything else. Without a
roadmap we only make it more complicated.


bye
Norman

Mime
View raw message