james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Hoffmann ...@byteaction.de>
Subject Re: LONG JAMES v2.4 Road Map
Date Fri, 15 Sep 2006 13:22:36 GMT
Hi Stefano,

Stefano Bagnara schrieb:
> So, do you think that current 2.3.0rc3 should be released as 3.0?
no. what is 2.3.0rc3 is, and stays 2.3.0rc3 and will be released as 
2.3.0 possible Bugs within it should be released as 2.3.1

Main development (your roadmap to 2.4) should now be 3.0 (Norman and 
Stefano, ...) anything that gets into 3.0 which would be great to have 
within 2.3 should go into 2.4 BUT by the 2.3/2.4 Maintainers (Noel and 
Vincenzo, ...)

Did that make it clear?
> IMO a string release plan is not in our possibilities now: we have 
> less than the equivalend of 2 fulltime developers working on it and 
> not on a regular basis (I don't know about Norman but I cannot take 
> the responsibility to work every day on James, I can only say I would 
> like to do that). Eclipse project as hundreds of developers supported 
> by their own companies. We could have much strict roadmaps and much 
> more stable releases and we would probably need a good project manager 
> to handle it (and not a "lazy" PMC ;-) ).
I see this a little dsifferent. I have been active with turbine for a 
while, and they had the same sort of problems you guys have now. Today 
development has stalled and the project (which is great) is short on 
developers willing to contribute. Because they do not see where or with 
what to help. Nobody sees the main target, or where the rpoject wants to 
go to.
> I still don't know what Vincenzo and Noel want to do with the 
> "next-minor" release so I'm not able to vote now the number of their 
> release. We also don't have a string roadmap for "next-major" release 
> (6 months) and I would be more inclined in using 2.x if we don't add 
> some more major change in current trunk, but I won't be against 3.0 or 
> any other number. I simply say that I'm fine with "next-minor" and 
> "next-major" and we can define the number as the release content is 
> more concrete. I think that in 3 months we'll be able to evaluate a 
> number for next-major, I can't say anything about next-minor until I 
> say the list of things that they want to backport (it seems to me that 
> the roadmap for this next-minor is not so defined yet)
Great. So let us keep it in that way. You are fine with
3.0 = Trunk
2.3 = Release Branch with possible bugfix sub releases
2.4 = Features that went into 3.0 which would be great to have within 
the 2.3 application layout (This Integration Effort is do be done by the 
2.4 maintainers)
>> So please step back from terms of throwing trunk on people and the
>> like, and keep focus on the project. Clear the misunderstandings out,
>> vote on release planning/cycles terminology. Keep focus on the
>> project in favor of interpersonal dislikings.
> I want to say it again because I don't want to be misunderstood. Don't 
> take my ideas or my objections as trunks on people and I'm just trying 
> to keep the focus on the project.
You weren't the one i was citing ;)
> I think we should use votes much more frequently and avoid endless 
> discussions. I already wrote a proposal for the next spf/mime4j 
> release, a proposal for a website change (to accomodate 2.2, 2.3 and 
> next-minor/next-major docs) and a proposal for the 
> next-minor/next-major stuff because I want to keep the focus on 
> concrete things.
> One of the part I liked much more in your message is the "X and Y 
> should be responsible for A and Z should be responsible for B". This 
> is really important in project management: we cast votes, we take 
> decisions, +1 votes should always mean active commitment toward a goal 
> and we should try to take responsibilities or to delegate to people we 
> trust some of them.
> As I said, I trust Vincenzo and Noel enough to know that if they work 
> to make a release they will do a good release so I don't need to 
> review and vote every single diff between trunk and 2.3 to decide what 
> to do: I know I may have different opinions on the risks related to a 
> given patch or to the importance a give feature has for our users, but 
> I understand that 1) I'm not the only developer, 2) this is not *my* 
> project, 3) other committers have enough experience to avoid big 
> mistakes.
That would be a giant leap into the right direction.
> PS: if it is "official" that your company support Norman in the james 
> work you may want to submit a Corporate CLA 
> (http://www.apache.org/licenses/cla-corporate.txt) as an additional 
> piece of paper to protect ASF from possible licensing problems.
If it wouldn't be official, I would have to fire him ;) I can sign this 
if it is necessary. No Problem.

Jürgen Hoffmann

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

View raw message