Hi, Not wanting to muddy the waters, I have used Code Review heavily in Shindig and to a lesser extent in Sling [1], partially because it has good but light integration with your local preferred scm tools.
I use git locally but it works just as well with svn, hg and others. It supports iterative patches with comments, [1] had 3 updates with comments by Felix. Finally if it all makes sense I put the final patch into Jira with the flag ticked, or now I commit. The reason I mention any of this, is it doesn't require any centralised work by anyone, ASFinfra or otherwise, you just use it and email the link to dev@ or put add it to a Jira. It also allows sharing of a patch *before* submitting to Jira and avoiding uncertain patches living in Jira. I am sure Crucible does the same, and this wasn't intended to be a "competitive analysis" Ian 1. http://codereview.appspot.com/67146/show On 16 Dec 2009, at 20:42, Dominik Süß wrote: > Yes I know - but the way of describing a but is a lightweight way. > Sometimes someone might see a problem without having a good solution and > copy & paste of code isn't good style (and might even be unreadable for > bigger fragments of code). > > So this is indeed not usefull for codesubmission but for participation > regarding the code quality. > JIRA should alway be part of this process. This is why I didn't mention this > step in my short list ;) > > Best regards, > Dominik > > On Wed, Dec 16, 2009 at 8:39 PM, Justin Edelson > <[email protected]>wrote: > >> Well, those steps would still be necessary to get changes made to trunk. >> >> Crucible just gives you >> a) a place to upload patches that is more code-friendly than JIRA >> b) a place to comment upon code inline both patch submissions and existing >> revisions >> >> And I suspect we'd still want bug reports to flow through JIRA, although >> they could certainly be tied to a Crucible code review. >> >> Justin >> >> 2009/12/16 Dominik Süß <[email protected]> >> >>> I'd strongly vote +1 since this could be a nice way of participation >>> without >>> the overhead of >>> - checkout >>> - fixing >>> - creating patch >>> - waiting till someone downloads the patch and checks the diff >>> - asking for some changes in the patch >>> ... >>> >>> especially for minor bugs this can be usefull and speed up the whole >>> development process. >>> Some of my coleagues started to use the crucible/mylyn plugin for eclipse >>> and although I haven't used this plugin myself it seamed pretty usefull >> to >>> me. >>> >>> Best regards, >>> Dominik >>> >>> On Wed, Dec 16, 2009 at 4:08 PM, Justin Edelson <[email protected] >>>> wrote: >>> >>>> One thing that wasn't enabled by default is the Crucible code review >>>> application. We use this extensively at MTV and it can be a very useful >>>> tool. Is there any interest in using Crucible for Sling? If so, I'll >> ask >>>> Atlassian to enable it. >>>> >>>> Justin >>>> >>>> On Tue, Dec 15, 2009 at 7:36 PM, Justin Edelson < >> [email protected] >>>>> wrote: >>>> >>>>> Up at: http://fisheye6.atlassian.com/browse/sling >>>>> >>>>> It looks like the hookup is already there between Fisheye and JIRA >> (see >>>>> http://fisheye6.atlassian.com/changelog/sling/?cs=890897 for >> example), >>>> but >>>>> not between JIRA and Fisheye. >>>>> >>>>> Justin >>>>> >>>> >>> >>
