We have a code review board (reviewboard.liftweb.net), but it's pretty geared towards changes. I don't know if it can be configured or used or what-have-you for reviewing the current state of code.
-Ross On Dec 29, 2009, at 4:39 PM, Erkki Lindpere wrote: > Another option would be to use a specialized code review tool, though > someone would have to host it. There's one thing that may not fit > about these, though: usually they are for reviewing *changes* and not > existing code. I don't know what the good ones are, but some otherwise > commercial products are free for Open Source projects (all of these > list Git support as well): > > SmartBear CodeCollaborator / CodeReviewer > http://smartbear.com/codecollab.php > http://smartbear.com/codecollab-buy.php <-- about open source > licensing > > Atlassian Crucible > http://www.atlassian.com/software/crucible/ > http://www.atlassian.com/software/crucible/licensing-faq.jsp#open-source > <-- about open source licensing > > I know there are some open source ones as well, personally I've only > used Crucible once and an open source tool a long time ago (don't > remember which one). > > Or how about writing a simple code review app in lift as an example > project :) > > Erkki L > > On Dec 29, 9:31 pm, Naftoli Gugenheim <[email protected]> wrote: >> Neat, thanks! >> Where to post it is a very, very good question. I would suggest not >> to invest much in a particular medium before you help us >> crystallize a good answer! >> (Attention all interested in the naming progess: I think we made >> good progress in terms of guidelines, and I think the next step is >> to discuss this question!) >> Originally the idea was to keep an organized Google Docs >> spreadsheet. I am not sure how sustainable the approach is though, >> because the amount of overhead may weigh it down too much. I am >> curious if that is part of why not much progress has been made. >> Jim, if you're reading this (I hope you are!) can you comment? >> The problem with just filing tickets is that everyone has different >> ideas, so discussion may be necessary to arrive at a consensus. At >> least posting it here first means if someone objects he will have a >> chance to voice his objection. >> One idea is one discusson thread, in the main Lift list, per Lift >> class. If everyone focuses on one or a few classes at a time it >> won't clog the list too much. >> Another idea of mine is to put the lift source file on Google Docs >> as a text document, and people can contribute to the discussion by >> writing inside the scaladoc comments. Nothing will get merged >> directly back to git; it's just a very lightweight way of >> discussing. E.g.: >> /** >> Xxxxx Xxxxxx xxx Xxx >> Erkki: why is xxx xx xxxxxxx >> nafg: well, xxx and xxx >> erkki: okay, but ... >> */ >> def someFoo ... >> >> What do you think? Very out of the box but it means very little >> copy-pasting work: the only overhead is uploading a source file; >> the rest is pure discussion in an inherently organized context. >> The disadvantage compared to threads on the list is that it won't >> get as much automatic public scrutiny, but whoever wants can have >> Google Docs email them any edits. >> Thoughts, everyone? >> Thanks. >> >> ------------------------------------- >> >> Erkki Lindpere<[email protected]> wrote: >> >> Hmm... actually seems like it will be a long document, I've already >> got several suggestions with 10 minutes of looking. Maybe I'll do a >> complete code review for the lift-webkit module if I have time / feel >> like it. Where should I post it? There doesn't seem to be a separate >> developers list. >> >> Erkki L >> >> On Dec 29, 7:58 pm, Erkki Lindpere <[email protected]> wrote: >> >>> Ok, I'll collect some specific issues I have with the API over a bit >>> longer period of usage and post them as an issue in GitHub? Or here? >> >>> Erkki L >> >>> On Dec 28, 4:40 am, Naftoli Gugenheim <[email protected]> wrote: >> >>>>> * there are several classes that have lots of methods in them that >>>>> don't all belong together. For example: S, LiftRules, I'm sure >>>>> there's >>>>> more. Some packages have too many classes as well. I think there >>>>> should be a cleaner separation of concerns. >> >>>> Again, I think there is a willingness to do something about this >>>> but we need >>>> your feedback. How would you categorize the concerns that S and >>>> LiftRules >>>> address? How would you like to see that categorization reflected >>>> in the API? >> >> -- >> >> You received this message because you are subscribed to the Google >> Groups "Lift" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected] >> . >> For more options, visit this group >> athttp://groups.google.com/group/liftweb?hl=en >> . > > -- > > You received this message because you are subscribed to the Google > Groups "Lift" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected] > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en > . > > -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
