Mark, I understand your position: I'm adding this mostly as FFT:
On 8/29/07, Mark Brouwer <[EMAIL PROTECTED]> wrote: > 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]. Honestly, I don't really see how CTR is going to help here. RTC isn't about lack of code review, it's quite the opposite actually: you still get notifications and ou can discuss changes and maybe revert/change the commit. In this case actually CTR can be a great way to foster discussion. > 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. Well, here I'm definitely seeing a problem. What I'm reading is that there are committers as in people with SVN write access who are no "committers" the way Apache intends them to be, as fully trusted members of the community who have a sound grasp of the technical side and, most importantly, know if and when to commit straight away or ask the community beforehand. If this is the case, then we have a different and major issue to tackle. > 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. This is a valid point: if you're used to this process, then just go for it. Do keep in mind, however, that there is always a trade-off between excellent *code* quality and excellent *community* quality. It has been said a number of times already how bad code creates great communities while excellent code rarely has a great community behind it. We don't need to go the the extreme here, but just know that the ASF values communities much more than code. > 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. Yes, that's possible. However, know that there might be some legal issues with hosting ASF code on external repositories. Probably this is not the case, yet it's something to consider. Ciao, -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
