james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Trunk and next-major features vs date (was: Next 2.x release)
Date Tue, 07 Nov 2006 17:57:21 GMT
Bernd Fondermann wrote:
>> I understand from this message that you instead are +0 on next-major
>> (with the additional doubts about feasibility) and +1 on working on
>> next-greater. I hope the other voters understood better the vote and
>> they don't think that Mar 2007 for next-major is unrealistic, otherwise
>> we have a problem in our voting process.
> No. My vote stands. With the exception of the release date.
> It really doesn't matter if it is ready March or July or September.
> What's important for me is: to work on trunk and keep compatibility.
> I am sure you are not saying that if I don't commit myself to a date,
> I cannot work on it.

You can work on it, but you should be aware that there is someone 
committed to that date and (if I thought this is what we voted, but we 
should probably discuss again and confirm this) that after that date 
your work on trunk won't be included on next-major but the following 

I know you only commit working and functional code, so it should be 
really an issue to you.

>> If this was not clear in the vote I invite you and any other committer
>> in the same shoes to resurrect that voting thread and cast new votes,
>> because otherwise here we have people working on roadmaps that have a
>> "false" consensus.
> A "roadmap" involves not only dates, but also features, architectural
> goals, run-time goals etc. Why do we talk about dates, version
> numbering and subversion branches first and features afterwards?
> It should be the other way round.
>  Bernd

Generally speaking I agree, but I think that the kind of roadmap you 
define works fine when you are a manager and you have a known man-power 
following your "rules".

We worked in a "weird" way for 2.3.0 because for almost an year I've 
been almost the only active committer. Now we are much more and this is 
cool, but everyone have different priorities and timings are really 
important to avoid loosing precious developer hours because of not 
"plannable" overlapping features.

I proposed to work on a time based roadmap instead of a feature based 
roadmap because it seemed to me the best compromise between the member 
goals, and because I think this is more "challenging" (Am I using 
existing words? ;-) )

I simply read 5 times the whole "JAMES 2.4 Road Map" thread and other 
threads used to discuss the roadmap and created a vote and a roadmap 
that imho is feasible: we can't discuss 2 months to decide what should 
be included in a release we want to publish in 2 months.

Imho we could even branch next-major today and start consolidating it (I 
really believe it is feature-consistent enough to be able to do this), 
but I think it is important to leave to committers a couple of months (3 
if you consider the date of the Road Map thread above) to work on the 
new features before starting consolidating again.
Furthermore we have some third party dependencies (dnsjava, javamail) we 
depend upon and we have to wait their final release to release 
next-major, so it would be really a pity if we'll have to wait for them.


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

View raw message