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
release.
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.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
