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.
