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