Gianugo Rabellino wrote:
Bottom line: I think CTR + a good use of common sense is more than enough. But then again, this is only me and RTC is kosher as well. If you're used to it, I see no reason to change that immediately.
Hi Gianugo, I see your points and as any process could work depending on the type of people and their willingness to make it work, I believe there are 2 issues not yet mentioned related to the River codebase that make RTC IMHO the best choice for the moment. I believe most parts of the Jini codebase represent extremely sophisticated/complex code designed with security in mind for each and every aspect as well as taking high levels of concurrency into account. Testing for this in a proper and cost efficient way is an art I'm still trying to master, I feel it is good to have a more rigid way of people looking into these aspects through code review [1]. Another one is that almost all committers are Sun based and we have only a few external ones and likely most committers only have their expertise in certain areas. I can imagine that it will be easier for Sun committers to 'nitpick' on proposed changes to the codebase instead of voting down a commit each time. I haven't work as their shrink ;-) so I can't tell whether they like the latter option more, but I can image that RTC will lower the barrier to comment on proposed changes and I suspect it will be quite a long way before we have a diverse group of committers that 'trust' each other enough to have CTR in place. Therefore I feel it is important to start with the customs that resulted in the excellent code quality we have right now, if it doesn't work we should change. I realize code-reviewing from patches alone is hard, and applying diffs you obtain from JIRA yourself for reviewing purposes is far from ideal. SVN is not the ideal tool to support this model, but it is also possible people expose their workspace through Mercurial e.g. (http://www.selenic.com/mercurial/wiki/) so people can pull in changes or sync to other people their workspaces. Ok, enough of my opinion ... [1] I like to emphasize that I don't see it as a replacement for testing, more to complement tests, especially for those cases one (or at least I) can't test (in isolation). -- Mark
