geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Arentz" <stefan.are...@gmail.com>
Subject RTC Thoughts
Date Sun, 18 Jun 2006 09:32:08 GMT
I've been reading the RTC discussion here and I would like to express
my thoughts about it. I'm not a comitter and not very familiar with
the Apache house rules so forgive me if I raise some silly points :-)

I think RTC will be good for maintaining a stable release. Keeping
1.1.x stable is extremely important for people running production on
it and if RTC will improve that stability and conformity then I think
it is a good procedure. Peer review always helps in that respect.  I
would call this 'Maintenance Mode RTC'. Commits in maintenance mode
will probably be small and quick to the point. So review is easy and
quick. Which is important because I think the team just decided to
release 1.1.1 in about two weeks.

On the other hand, I'm afraid that the possible burocracy and
'latancy' of RTC will put Geronimo much further behind than it already
is in the app server world. As Aaron pointed out Geronimo is very
innovative on certain areas while significantly behind in others. With
EJB3 probably being the most important. (At least for industry/j2ee
standards)

Working on something big as EJB3 is imo only going to work if a small
group of core developers can move some mountains of code and not be
bothered by the RTC process while they are still playing around,
discovring how to builld that new module, reaching a point where it
can be called a first alpha release and thus committing many little
changes. I would call this 'Sandbox Mode RTC'. Needing votes here
delays things and also makes it very difficult to do patch management
because while you are waiting for people to vote you have probably
alreasy invalidated your patches since you did not stop working during
that voting period.

Geronimo does has some very strong features  that should be used to
make the 'Sandbox Mode RTC' process easier; gbeans and plugins. Many
things, even the whole new Klustering and Kache architecture for
example, can mostly be developed outside of the main project and then
submitted as a new component as a whole. This just only requires a
stable 'core'.

A module or component can then be accepted / voted for as a whole when
code is stable enough to be included in Geronimo. Does this make the
process less open? Does this translate to monster commits that nobody
is going to read? Personally I don't think so. The code is still
available (also during development), people can still jump in and help
and you can still follow the progress and express your opinion when
you see things you don't like. There will still be someone who takes
the lead (and responsibility!) for a component. From what I've seen
the last 18 months the ocmmiters on this project have always been open
for discussion and change. The trust is there. I think they have
established that and proved that they can 'run' a large community
project like Geronimo.

I understand where Ken is coming from and how RTC works fine for a
project like Apache's httpd. But just look at the number of
sub-projects that Geronimo contains now, well over a hundred, and you
might realize that the traditional Apache development model might not
be suited anymore for a project of Geronimo's scale. I don't know what
that should mean in practice though. But I know for sure that Geronimo
is not going to be the last project of this scale. This is a somewhat
deeper thought but I think very essential in a RTC discussion for a
project this complex.

 S.

Mime
View raw message