Hi Guys and Gals,
I just wanted to chime into this thread since the discussion is quite
lively right now. Obviously not being a commiter on the project directly
I don't really have a leg to stand on from a developer perspective, but
I do come from a user perspective having worked through various issues
with using Geronimo over the past year, and have been writing what I
find for the community to learn from.
Development sure has slowed down recently. That's true. But, on the
other hand, I have been able to check out the source tree and build it
every single time I've tried lately. That is important to me when I'm
trying to get some work done. But of course there's other ways to
achieve this stability. For instance, an unstable and stable branch
structure could cause the same stability for those of us in the
community trying to get some work done. You folks in the developer
community work on the trunk, and migrate fixes over to the stable
branch, promoting the unstable branch to stable periodically. The
problem with that approach is that it takes a lot of time to migrate
fixes to the stable branch, and sometimes with large enough changes,
it's next to impossible not to destabilize the stable branch.
From my point of view I feel that slowing down the development at this
point needs to be carefully balanced with the implementation of the Java
EE 5 functionality. It would seem prudent to me, keeping in mind I have
no real voice in your developer community, that two things need to be
done. Keep part of the Geronimo tree stable for those of us who need to
work with this stuff, while at the same time take the leash off those
developers that feel the need to implement the Java EE 5 functionality,
providing them a place where they can build out the new functionality as
fast as possible with less restriction. In my opinion that is the most
important thing for moving application servers into the future.
The fact that it took me over a week (of evenings) to write out a little
J2EE application that had 1 CMP bean, 1 Session bean, 1 MDB bean, and a
simple list based Add, Modify, Delete Struts application says something
to me. Much of the time was trying to figure out what was going on
between the EJB and Web containers (what JNDI names were valid and so
on), trying to figure out what my deployment descriptors and deployment
plans should say, and how to hook up my MDB bean to a GBean timer thread
that would pulse the message queue periodically. The rest was all
standard boilerplate code. Much of that will dissapear in a Java EE 5
world. It makes me yearn for next summer when Geronimo would have had
those features too (or still may).
With this 'new' (I use the word 'new' mostly in ignorance, for it may
not be so) development process that has been imposed I feel that goal
will be unattainable. I realize there is a lot of full-time developer
horsepower behind the Glassfish project at Sun, but it's there for
people to try out now, and people will: it's a big draw for developers.
I also want to begin using Java EE 5, and would like that learning to be
done on a Geronimo platform because I agree more with the licensing
philosophy you have. Wrapping up the project in a red-tape effort to
produce stability at this point may be a mistake (I am trying to be
generous with my assessments even though I think it will have more dire
consequences than I'm letting on).
I've likely already said too much. In summary, I'll say: Stability is
good, put it on a stable branch. Then let the unstable development
happen more freely (perhaps a single +1 to allow commits, without a
patch review to at least have people state their intents publicly, but
not have such a delay as 'must be a patch' and have three +1s). But for
the stable branch, the 'must be a patch' and have 3 +1s would be the
only way.
Cheers.
-Neal
Dain Sundstrom wrote:
Ken, I think you have a faulty assumption that this project cares
about what you call "tested quality". I for one am fine with changes
that haven't been tested to the level you are demanding from this
project. Personally, I'd like to see less perfect software that
people want to use, other than perfect software that is so
functionally incomplete that no one will uses it.
If the community agrees with me, is there anything we can do to change
your process or are we just stuck with it?
