Jürgen Hoffmann wrote:
Right now you are quarreling about things that should be defined once
and then be clear to everyone. Looking at the Message History,
quarreling and endless discussions are quite common to this project.
Welcome to server-dev ;-)
I see and understand that there are different understandings about
release planning. So I want to first lay the cornerstone for the next
release. Please vote on which mechanism you want to keep on
developing. Vincenzo suggested the most common approach
[...]
From what I understood from the recent posts, is that release planning
was handles different in the past, and why should one change it now,
when it was different in the past. Well IMHO we all evolve with a
project. Sometimes certain decisions are good, sometimes they are bad.
But just because there have been bad decisions does not mean to keep
bearing with them instead of changing them to something better.
So, do you think that current 2.3.0rc3 should be released as 3.0?
But the version numbering is only solving half the problem. The next
thing is to define what should be inside a Release. this should first
be analyzed by topic i.e. will feature a be an incompatible change, or
not.
I think that the version numbering is solving 5% of the problem: if we
don't write the new features we could have defined the best version
numbering scheme ever, but we would never use it.
Successful Open-Source Projects (Eclipse, ...) have a strict Release
Plan (Minor Releases every 6 Months, Major Releases every Year), with a
certain set of features. The Feature Sets should be chosen, so that the release
is
possible. The Projected Release Dates are fixed to some
extend. If a Release Date is coming closer, and it is obvious that a
certain feature can not be implemented/integrated to the projected
date, there should be a vote on what to do. Move the Release Date, or
Move the Feature to the next Release Cycle.
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 ;-) ).
Those Rules should be clear to everyone, so noone has to argue or
quarrel about what is a next release.
That said/written please vote about how release planning should be
considered in the future.
I would consider the discussed road map to be the 3.0 road map,
Norman and Stefano should be responsible for its development. Features
that are wanted in 2.4 should be backported by the people that want
it within 2.4 release. Noel and Vincenzo should be responsible fpr the
2.4 release. If there are Problems during backporting/migration of
features Stefano and Norman should be available for helping, but
should keep their focus on 3.0
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)
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.
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.
Again I know I am an Outsider, but still I hope you consider my
suggestions to this project
Kind regards
Juergen Hoffmann
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.
Stefano
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
