On Jun 12, 2006, at 12:09 PM, Alan D. Cabrera wrote:
Dain Sundstrom wrote:
I am a bit torn here, because I agree with both of you depending
on which code we are talking about. Geronimo is a large project
and I think we will be doing ourselves a disservice if we attempt
to treat all of the code the same. For example, I think Alan's
comments apply best to the core transaction processing parts of
geronimo, and I think think Aaron's comments apply best to non-
critical parts of the server like the console and tooling. I
would be upset if someone tried to add a new feature to the core
server in a micro release, but if they say added a new command to
the cli or a new portlet, I wouldn't be upset at all.
Can we find a compromise where critical code moves more
conservatively and non-critical code gets more liberal rules? If
not, I think we should start talking about how to divide up the
code base into independently versioned released components. This
will take a lot of effort in architecture and organization in our
team. I'd rather not do it at this time, but maybe the time has
come sooner that I wanted.
Core stuff is more important to you because, well, that's what you
work on. What you consider "fluff" stuff may be critical to others.
Alan, that was not my point. There is stuff that applications use
directly (e.g., the tx mgr, ejb container, servlet engine, etc) and
then there is stuff like the console and sample applications. If my
tx mgr, breaks I'm screwed where as if the console breaks, it isn't
as bad, and if a sample app breaks. Not all code has the same
constraints.
Splitting the product into separate lines would not cause time
tested, industry standard, principals to not apply to apply to
those new proposed product lines. I would feel just as strongly
about the pieces as I would the whole.
I agree with you, but it would mean that each line would progress at
its own speed. I would expect stuff like the console to have several
major revisions for the next few years, where stuff like the
transaction processing part of the server would have a major release
every 18 months.
Anyway, I've made my point, and I will be happy with what ever the
project agrees on as long as everyone is equally happy (or unhappy).
-dain
