X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C8A8D0.74ABD488@onstor-exch02.onstor.net>; Sun, 27 Apr 2008 18:37:44 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C8A8D0.74ABD488"
References: <WEBMAILcafI0L2XFGux000005af@mail.onstor.com><BB375AF679D4A34E9CA8DFA650E2B04E04344C66@onstor-exch02.onstor.net> <20080426150504.195c0b39@ripper.onstor.net>
Content-class: urn:content-classes:message
Subject: RE: PERFORCE change 28985 for review
Date: Sun, 27 Apr 2008 18:37:44 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E042F0161@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PERFORCE change 28985 for review
Thread-Index: Acin6ZYVvIhOXPsjS6qnoK7IpCVGeAA5DBD4
From: "Larry Scheer" <larry.scheer@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>,
	"Tim Gardner" <tim.gardner@onstor.com>
Cc: "Danqing Jin" <danqing.jin@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8A8D0.74ABD488
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Well, you have to pay attentention to more than just how the branch was =
initially created. If the release branch is a continuation of a heavily =
cherry-picked branch, even though a common ancestor can be traced back =
to dev, integrations back into dev from files that have diverged greatly =
over time can create more problems than the proposed change resolves.

That is why the policy of not integrating from a release branch back =
into dev was instituted. It can be done, but as you say should only be =
done carefully and sparingly. It also should only be done with the =
consent of the current release project manager.=20

IMO, doing this without Tim's knowledge or approval is just asking for a =
swift ass-kicking.

Larry

-----Original Message-----
From: Andy Sharp
Sent: Sat 4/26/2008 3:05 PM
To: Tim Gardner
Cc: Danqing Jin; Larry Scheer
Subject: Re: PERFORCE change 28985 for review
=20
As long as there was a common parent in both branches, it doesn't
matter which way you do the integrate.  But if there wasn't, then this
kind of integrate could wipe out the history of a file in dev, so it
should be done carefully and sparingly.

On Fri, 25 Apr 2008 21:41:43 -0700 "Tim Gardner"
<tim.gardner@onstor.com> wrote:

> Why are changes being integrated from a release branch into dev?
> Changes are supposed to be made in dev and pushed out to release
> branches.
>=20
> ________________________________
>=20
> From: Danqing Jin
> Sent: Fri 4/25/2008 5:20 PM
> To: Amit Bothra; Andy Sharp; Chris Vandever; Danqing Jin; Deepak
> Veliath; Eric Barrett; Henry Lau; Ian Brown; Jan Seidel; Jobi
> Ariyamannil; Jonathan Goldick; Larry Scheer; Maxim Kozlovsky; Mike
> Lee; Narain Ramadass; Sandrine Boulanger; Sripal Surendiran (HCL);
> Svati Chandra; Tim Gardner; YiFeng Liu Subject: PERFORCE change 28985
> for review
>=20
>=20
>=20
> Change 28985 by danqingj@danqingj-dev on 2008/04/25 17:15:31
>=20
>         Integrate change 28983 from R3_1_0_rel branch to dev.
>       =20
>         Changes for defect 23447 to close the window in
>         fs_dr_rmcInitiateFS2SSCSession() where rmc_open() succeeds
>         but fs_dr_rmcOpenYield() has not received ack for the open.
>       =20
>         Reviewed by: narainr
>=20
> Affected files ...
>=20
> ... //depot/dev/nfx-tree/code/sm-fs/fs-dump-restore-rmc.c#3 integrate
> ... //depot/dev/nfx-tree/code/sm-fs/fs-dump-restore-rmc.h#2 integrate
> ... //depot/dev/nfx-tree/code/sm-fs/fs-dump.c#18 integrate
> ... //depot/dev/nfx-tree/code/sm-fs/fs-restore.c#4 integrate
>=20
>=20
> http://liszt:1818/@md=3Dd&cd=3D//depot/$c=3DG35@/28985?ac=3D10
>=20
>=20


------_=_NextPart_001_01C8A8D0.74ABD488
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: PERFORCE change 28985 for review</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Well, you have to pay attentention to more than just =
how the branch was initially created. If the release branch is a =
continuation of a heavily cherry-picked branch, even though a common =
ancestor can be traced back to dev, integrations back into dev from =
files that have diverged greatly over time can create more problems than =
the proposed change resolves.<BR>
<BR>
That is why the policy of not integrating from a release branch back =
into dev was instituted. It can be done, but as you say should only be =
done carefully and sparingly. It also should only be done with the =
consent of the current release project manager.<BR>
<BR>
IMO, doing this without Tim's knowledge or approval is just asking for a =
swift ass-kicking.<BR>
<BR>
Larry<BR>
<BR>
-----Original Message-----<BR>
From: Andy Sharp<BR>
Sent: Sat 4/26/2008 3:05 PM<BR>
To: Tim Gardner<BR>
Cc: Danqing Jin; Larry Scheer<BR>
Subject: Re: PERFORCE change 28985 for review<BR>
<BR>
As long as there was a common parent in both branches, it doesn't<BR>
matter which way you do the integrate.&nbsp; But if there wasn't, then =
this<BR>
kind of integrate could wipe out the history of a file in dev, so it<BR>
should be done carefully and sparingly.<BR>
<BR>
On Fri, 25 Apr 2008 21:41:43 -0700 &quot;Tim Gardner&quot;<BR>
&lt;tim.gardner@onstor.com&gt; wrote:<BR>
<BR>
&gt; Why are changes being integrated from a release branch into =
dev?<BR>
&gt; Changes are supposed to be made in dev and pushed out to =
release<BR>
&gt; branches.<BR>
&gt;<BR>
&gt; ________________________________<BR>
&gt;<BR>
&gt; From: Danqing Jin<BR>
&gt; Sent: Fri 4/25/2008 5:20 PM<BR>
&gt; To: Amit Bothra; Andy Sharp; Chris Vandever; Danqing Jin; =
Deepak<BR>
&gt; Veliath; Eric Barrett; Henry Lau; Ian Brown; Jan Seidel; Jobi<BR>
&gt; Ariyamannil; Jonathan Goldick; Larry Scheer; Maxim Kozlovsky; =
Mike<BR>
&gt; Lee; Narain Ramadass; Sandrine Boulanger; Sripal Surendiran =
(HCL);<BR>
&gt; Svati Chandra; Tim Gardner; YiFeng Liu Subject: PERFORCE change =
28985<BR>
&gt; for review<BR>
&gt;<BR>
&gt;<BR>
&gt;<BR>
&gt; Change 28985 by danqingj@danqingj-dev on 2008/04/25 17:15:31<BR>
&gt;<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Integrate change =
28983 from R3_1_0_rel branch to dev.<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Changes for defect =
23447 to close the window in<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
fs_dr_rmcInitiateFS2SSCSession() where rmc_open() succeeds<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; but =
fs_dr_rmcOpenYield() has not received ack for the open.<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Reviewed by: =
narainr<BR>
&gt;<BR>
&gt; Affected files ...<BR>
&gt;<BR>
&gt; ... //depot/dev/nfx-tree/code/sm-fs/fs-dump-restore-rmc.c#3 =
integrate<BR>
&gt; ... //depot/dev/nfx-tree/code/sm-fs/fs-dump-restore-rmc.h#2 =
integrate<BR>
&gt; ... //depot/dev/nfx-tree/code/sm-fs/fs-dump.c#18 integrate<BR>
&gt; ... //depot/dev/nfx-tree/code/sm-fs/fs-restore.c#4 integrate<BR>
&gt;<BR>
&gt;<BR>
&gt; <A =
HREF=3D"http://liszt:1818/@md=3Dd&cd=3D//depot/$c=3DG35@/28985?ac=3D10">h=
ttp://liszt:1818/@md=3Dd&cd=3D//depot/$c=3DG35@/28985?ac=3D10</A><BR>
&gt;<BR>
&gt;<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C8A8D0.74ABD488--
