AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:
CFG:
PT:0
S:andy.sharp@lsi.com
RQ:
SSV:mhbs.lsil.com
NSV:
SSH:
R:<brian.stark@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	861DA0537719934884B3D30A2666FECC010DFDF15A@cosmail02.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 2 Feb 2010 11:33:19 -0800
From: Andrew Sharp <andy.sharp@lsi.com>
To: Brian Stark <brian.stark@lsi.com>
Subject: Re: code reviews
Message-ID: <20100202113319.2b3725fd@ripper.onstor.net>
In-Reply-To: <861DA0537719934884B3D30A2666FECC010DFDF15A@cosmail02.lsi.com>
References: <861DA0537719934884B3D30A2666FECC010DFDEF62@cosmail02.lsi.com>
	<4B677404.1070005@lsi.com>
	<861DA0537719934884B3D30A2666FECC010DFDEF8E@cosmail02.lsi.com>
	<20100201173957.42b70c5a@ripper.onstor.net>
	<861DA0537719934884B3D30A2666FECC010DFDF15A@cosmail02.lsi.com>
Organization: LSI
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Brian, here is the reply to Max's reply as I have written it so far.  I
have not sent it to Max yet.

a

On Tue, 2 Feb 2010 11:54:34 -0700 "Kozlovsky, Maxim"
<Maxim.Kozlovsky@lsi.com> wrote:

> Andy,
> 
> You know you are downright crazy, do you :) ? 

I've always been comfortable with that fact ~:^)

> Nobody is going to submit any code to nfs or cifs or virtual servers
> or networking or any other area that I am the lead of that I do not
> approve.

You're always free to review any code, pre- or post submittal.  As
you know, I post-review changes all the time.  And I'm glad to hear
that you are feeling responsibile for various areas of the
product.

> We did not have to bring this up before because you changes were very
> good, as you said it is hard to disagree about them. After the latest
> piece of shit that Bill submitted for review and the comments he made
> about "voting" about the review outcome I felt we need to reinforce
> the rules. 

As you know, any change is going to be controversial to the original or
main author of the code.  I get that.  And yet we do need to port this
stuff.  Please try to work out with Bill whatever big things you feel
you are in disagreement about.  I haven't seen anything in his latest
changelist, apart from the lack of p4 integrate v. p4 add/delete, that
is too terrible.  He's been telling me that you have a problem with
req_header_something, but I didn't see anything that looked obviously
broken.  Some things are going to look a littel different than they used
to.  I sent him my review yesterday asking him to change a lot of
stuff.  Much of it was header spam and places where he evidently didn't
do ... a p4 integrate, so he didn't have the last couple of changes
that were made to some files. We'll see what comes out of that.

> Rendell is working on the vsvr code but he is not going to check in
> anything without my review. The more Bill talks about "rewriting the
> vsvr code" the more I feel this is not going to be an easy one.

Again, I'm always glad to have your input, but since I designed the new
vsvr implementation, which is completely new, I feel that I am
ultimately responsible for it.  But don't worry, I won't let 'em screw
it up ~:^)

> Max
>  
> -----Original Message-----
> From: Andrew Sharp [mailto:andy.sharp@lsi.com] 
> Sent: Monday, February 01, 2010 5:40 PM
> To: Kozlovsky, Maxim
> Subject: Re: code reviews
> 
> Hi Max,
> 
> You know you're completely dillusional sometimes, right? ~:^)
> 
> I'm fine with you herding over the FP code: as far as I'm concerned,
> you're the team lead on the FP code and call the shots there.
> Everything else is my responsibility, and I need to guide the coding
> and porting in the txrx areas, especially with these guys.  With the
> exception of the clustering code which would be submitted to Chris if
> you want to live ~:^)  Of course I *always* welcome your input.
> Mutual code we should work out on a case-by-case basis if we don't
> agree, but I don't see us disagreeing much.  To be honest, it has
> been a tad difficult to get Bill to use perforce correctly when
> moving code, but I'm still trying to get that to improve.
> 
> As far as functional changes go, there should not be any, except in
> the areas where things have to be ported, and of course the
> networking. Any functional changes either have to go through you for
> the FP stuff, or go through the design review process.  But as I
> said, there shouldn't be any.
> 
> Rendell's working on the vsvr code, we agree on that, yes?
> 
> Thanks,
> 
> a
> 
> On Mon, 1 Feb 2010 18:00:23 -0700 "Kozlovsky, Maxim"
> <Maxim.Kozlovsky@lsi.com> wrote:
> 
> > I am sorry that you were insulted, I was simply explaining how the
> > things are organized. I already am the "lead code reviewer" for any
> > of the code areas I mentioned, and I have not heard anything to the
> > contrary yet. 
> > 
> > The process you suggested will not work. I have to review the
> > changes to the listed directories. I can guarantee 48 hours
> > turnaround time for reasonably sized change lists.
> > 
> > -----Original Message-----
> > From: William Fisher [mailto:bill.fisher@lsi.com] 
> > Sent: Monday, February 01, 2010 4:38 PM
> > To: Kozlovsky, Maxim
> > Cc: Stark, Brian; Fong, Rendell; Sharp, Andy; Fisher, Bill
> > Subject: Re: code reviews
> > 
> > Kozlovsky, Maxim wrote:
> > > Hello,
> > > 
> > > I think there is some confusion on Bill's side on how the code
> > > reviews are done. It is not a voting process.
> > 
> > 
> > For example, you cannot check in changes to the following
> > directories without my approval:
> > 
> > 
> > Sm-nfs, Sm-cifs, Sm-pkt, Sm-req-queue, Sm-tpl, Sm-search, Ssc-vsd, 
> > Sm-evm, Sm-dcache, Sm-evm-srvr,
> > 
> > Sm-dp-proxy, Sm-vsvr, Sm-open, Sm-cifs-rpc, Sm-netbios, Sm-rmc,
> > Ssc-rmc, sm-lock Sm-whatever Ssc-everything else,
> > 
> > 
> > I must have missed about dozen or so.  You can send code for review
> > to however many people you like,
> > 
> > but in the end there is only one person who decides on what is
> > checked in to a particular directory.
> > 
> > You can't ask Andy or Rendell to review changes to ssc-cluster,
> > this should be Chris.
> > 
> > The process can be altered only for trivial changes. For example 
> > everybody can review the
> > 
> > change of replacing malloc-api.h with linux/slab.h, or printf with 
> > printk, or %lld with %ld in a bunch of files,
> > 
> > in fact it will be a waste of time to ask 3 different persons to do
> > that.
> > > 
> > > Max
> > > 
> > > 
> > This is totally rude and very insulting to me and
> > probably Rendell and Andy as well. They can speak
> > for themselves
> > 
> > Andy and I have been working on this code for over a year just
> > fine with the existing code review process we have been using.
> > 
> > This is Brian's call NOT yours IMHO.
> > 
> > If he appoints you the "lead code reviewer" then your
> > algorithm will apply. In the mean time, we'll continue
> > the "team" approach.
> > 
> > Andy and I have spent MONTHS editing the txrx code into
> > the Linux tree and have done LOTS of work to preserve
> > the EEE API's to made the code as "portable" as possible.
> > 
> > The header files were a complete mess, lots of stuff in
> > various bogus places, 100's of files including header
> > files that are not required nor used. Virtually poor
> > laying of the data structure includes for such as large
> > software project. Don't get us started. We have kept
> > our mouth shut and simply edited the files to "fix"
> > the problem and move toward a more consistent set of
> > source code. If you disagree, then so be it.
> > 
> > I suggested to Brian a new approach, anyone of the three
> > of us can review the code, only one is required and it
> > should be done within 48-hours of the request.
> > 
> > Rendell and I have been blocked for some time due to getting
> > "agreement" and review of our changes.
> > 
> > -- Bill
