geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neal Sanche <n...@nsdev.org>
Subject Re: Request change to RTC Process
Date Sat, 17 Jun 2006 21:00:06 GMT
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?


Mime
View raw message