This is a major major reason I think we have outgrown milestones.
-David
On Jul 20, 2005, at 10:31 AM, Jeff Genender wrote:
Ok...if we are in favor of an August M5, then I am cool with this.
I want to point out a little history to understand why there is
some passion in getting this into M4.
My understanding about M(X), is the M stands for Milestone. I
believe that you hit a milestone based on a set of criteria. I not
only understood that we had concensus that this would be a part of
milestone 4 and thus fit the criteria, but I was specifically asked
by one of the committers on the project to get it done fast so it
can be in M4. I worked very hard to get this out. It was somewhat
disconcerting to me that this got kicked back to M5 after all of
this...as I could have taken my time.
I would only ask that A) M5 come in a relative short time
period...and more importantly, that B) we decide ahead of time what
is in the milestone, and cut based on the milestone roadmap's
requirements of included options, as opposed by date. Although it
would seem that A conflicts with B, it does not. If we keep our
list relatively short, A will work with B.
Finally, IMHO, there has been too much committer talk and decision
on this subject. I really would love to hear what the community
wants in M4 and M5. The community's voice should be the most
important.
Jeff
David Jencks wrote:
I am extremely strongly in favor of only bug fixes for M4 and
putting out M5 in mid august and 1.0 in mid sept.
I'd like to point out that re-branching at this point is
essentially abandoning M4 for M5. I have committed substantial
changes to head that are not yet necessarily completely stable and
are also not quite complete. If we rebranch, we won't be able to
get the new M4.5 out before mid august anyway.
I abandoned my hopes of getting all the work I am putting in head
into M4: after some consideration I decided that it was more
important to get M4 out than my favorite features in, even though
I was sure they would not be destabilizing. There's some
difference in that my features have no discernable impact on the
normal user, but still :-)
thanks
david jencks
On Jul 20, 2005, at 6:56 AM, [EMAIL PROTECTED] wrote:
On the Geronimo IRC channel there was talk about the Tomcat/Jetty
Picker
not going in M4 because it is now involving more code changes
than what
people thought they had agreed to. This was a surprise to me and
after
discussion it was proposed that I call for a vote.
Before I do, I thought a little background might be helpful..
Back in the mail thread "Preparation for M4 -- jetty vs tomcat or
jetty
and tomcat (two builds)" on 5th of July it was agreed that there
would be
a Tomcat and a Jetty build of Geronimo.
In the mail thread "Wait or not? Respond quick. (M4 -- 24 hour
notice of
branch)" on 9th of July, it appears nobody asked to hold off
creating the
branch to do the work for the Tomcat / Jetty builds. Maybe it
was just
assumed it was going to be simple changes in the branch, or it was
forgotten.
In the mail thread "M4 Status", started by Aaron on 18th July, he
said "I
believe Jeff is working on separate plans for Tomcat and Jetty
builds, so
we can produce two separate distributions as people seemed to
prefer." .
Alan responded "I think that the notion that adding new features
into a
QA branch is a bad idea stands, regardless of how simple the
changes are
and how simple it is to merge them. It's simply bad form". Alan
then
said "I'm not opposed to the what and why. I am opposed to the
how."
David Jencks also agreed with Alan in the mail thread.
So it seems that people are unhappy with the "how" as Alan said.
Since it was already agreed that we are to have separate Tomcat
and Jetty
builds in M4, that decision should not be questioned and as a
reminder
Jeff's changes have the following benefits:
* Less user problems - the previous method of having to edit many
files is
prone to failure, it caught me out many times, and I have seen
others get
caught out!
* We don't have to document the M4 way of configuring the web
containers
and the M5 way of configuring. This makes the instructions more
complicated and makes it harder for other forms of documentation
to stay
relevant (e.g. articles and Aaron's book).
* Documentation does not have to be changed when we reach M5.
* We are seen to be trying to minimise changes that impact
configuration
between releases.
Looking back, it appears we branched too early.
I propose that we vote on the "how" with the following options:
a) Merge Jeff's Tomcat/Jetty switch changes into the M4 QA
branch
b) Make a new Geronimo M4 QA and OpenEJB M4 QA branches from
HEAD
when it is stable.
John
This e-mail message and any attachments may contain confidential,
proprietary or non-public information. This information is intended
solely for the designated recipient(s). If an addressing or
transmission
error has misdirected this e-mail, please notify the sender
immediately
and destroy this e-mail. Any review, dissemination, use or
reliance upon
this information by unintended recipients is prohibited. Any
opinions
expressed in this e-mail are those of the author personally.
