Re: [imp-dev] How to do code review and the Atlantic ocean

[Stan Sutton <suttons@xxxxxxxxxx>]

I generally agree also.  But I
agree with Bob's point that it might be good to assure first (by one of
the other approaches?) that the prospective bits are likely to wind up
being accepted.

Also, we have not been very nimble about
creating branches in SVN (we're still putting off branching for different
versions of Eclipse)--so we'll have to get over that.  A question
I have is whether there's a possibility of getting a repository that is
too bushy and overgrown--difficult to understand or difficult to work with.
 Also, will we want the full version history of all of these contributions-under-review
once they are either a) rejected or b) successfully merged?  If not,
is there a way to prune the junk out of the repository?

Do we have any good examples of how
other groups might address this?  Maybe there are some documents on
line about recommended practices ...

Stan


Stan Sutton, Ph. D.
IBM T. J. Watson Research Center
19 Skyline Drive, Hawthorne, NY 10532 USA
telephone:  1-914-784-7316, FAX:  1-914-784-7455, T/L 863
e-mail:  suttons@xxxxxxxxxx, Stan Sutton/Watson/IBM@IBMUS

"Robert M. Fuhrer" <rfuhrer@xxxxxxxxxxxxxx>
Sent by: imp-dev-bounces@xxxxxxxxxxx

06/06/2008 10:16 AM

Please respond to
IMP Developers List <imp-dev@xxxxxxxxxxx>

To	IMP Developers List <imp-dev@xxxxxxxxxxx>
cc
Subject	Re: [imp-dev] How to do code review and the Atlantic ocean

Jurgen Vinju wrote:
> Hi!
>
> I was just thinking about how to do this code reviewing stuff. The
> scenario is that
> one of us (an IMP committer that is) has cool new code, or a nice
> bugfix to add to IMP,
> but first wants the rest to review the code.
>
> Possibilties:
>   a) We email the code to each other, and chat about on the phone
[not good]
>   b) We make a bugzilla entry and attach a patch, and CC everybody
we
> want to review the code [ok-ish]
>   c) We make a branch in subversion and organize via bugzilla
to
> review the code and merge the code
>       to the trunk [good]
>   

Generally, (c) seems the right way to go, though I think it's a good idea
to discuss the intention of the patches/additions even before branching,
so the community can decide whether the feature/fix is basically pointing
in the right direction (well motivated, has roughly the right design, etc.).

> I like the third possibility best because then we can all contribute
> to improve the 'patch' before it is
> merged to the trunk. Also the patching process itself is taken care
of
> by subversion, and bugzilla
> helps us to keep track of things that still need merging or reviewing.
>   

Agreed.

-- 
Cheers,
  -- Bob

--------------------------------
Robert M. Fuhrer
Research Staff Member
Programming Technologies Dept.
IBM T.J. Watson Research Center

IMP Team Lead (http://eclipse-imp.sourceforge.net)
X10: Productivity for High-Performance Parallel Programming (http://x10.sf.net)


_______________________________________________
imp-dev mailing list
imp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/imp-dev