On Thu 21 Feb 2008 at 06:20PM, James Falkner wrote:
> Darren J Moffat wrote:
> > I'm not sure I understand the problem you are trying to solve.
>
> Well the end result would be increased webrev adoption, for
> projects that have a process in place that does not use webrev.
> People may not want to have a new thing in that process since
> the existing process covers code reviews via diff output.
>
> A specific problem I'm trying to solve is to increase code review
> accuracy. We've had a few cases where the add/remove of a file
> (or forgetting to add/remove) caused a bug, and it would have been
> more obvious if there was a webrev (which automatically identifies
> new/obsolete files).
>
> Also, in general, webrevs are IMO vastly superior to 'hg diff'
> output for more than the trivial changes. I go cross-eyed looking
> at more than a few screenfuls of diff output.
All fine. A web service is one way to solve this, surely.
> > If hg diff output for the repository can be generated by the user why
> > can't webrev out be ?
>
> Also, they may not be comfortable copying the results (e.g. scp
> webrev [EMAIL PROTECTED]:foo) or may not be possible (e.g.
> Windows with no pscp or something).
If you need a small gui to drive webrev, by all means, write one.
> > Is the idea that there is a central codereview database with permalinks
> > or is this more like cr.opensolaris.org ?
>
> Yeah that's the idea. - to have a cr.opensolaris.org with
> an archive of all webrevs that are easily accessible/indexable/etc.
> One that the developer doesn't have to remember the site name
> or remember to create a consistent directory structure.
"A cr.opensolaris.org with an archive of all webrevs that are easily
accessible/indexable/etc" sounds pretty far afield from the problem
you cite above.
While RFEs are great and all, currently, I'm the only person who has
ever done a lick of work on cr.o.o, despite calls for help on multiple
occasions.
Currently, I'm working on an ATOM feed for newly posted reviews. Next
after that will be enhancing webrev to produce some machine-consumable
metadata (which should make said feed quite a bit richer).
I have intentionally avoided implementing any sort of active "stuff" on
the site: no CGI, no JSP, no MySQL, no Rails, etc. Since there's only
me, I need to keep it very simple.
I'd invite those who want to help improve cr.opensolaris.org (by writing
code or helping to maintain what we have) to let me know.
-dp
--
Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
