WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] Signed-off-by again

To: "Anthony Liguori" <aliguori@xxxxxxxxxx>, "Muli Ben-Yehuda" <mulix@xxxxxxxxx>
Subject: RE: [Xen-devel] Signed-off-by again
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Tue, 11 Apr 2006 17:59:50 +0100
Cc: Ross Maxfield <rmaxfiel@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Hollis Blanchard <hollisb@xxxxxxxxxx>, mdday@xxxxxxxxxx, Ewan Mellor <ewan@xxxxxxxxxxxxx>
Delivery-date: Tue, 11 Apr 2006 10:00:12 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZc+ty35/Yqwj/XQHSgCJ3J/jajKAAjEx3w
Thread-topic: [Xen-devel] Signed-off-by again
> Having another changeset is so trivial that IMHO one should 
> always just hg import the original patch and then add another 
> one on top of it.
> 
> Personally, I'm very interested to see the things about a 
> patch that warrant modification so I can avoid doing them in 
> my own patches.  
> Having that expressed as a separate changeset is very useful 
> (especially if it has a nice commit message explaining the 
> reasons for the modification).

In most cases the modifications are just to fix merge conflicts, or make
trivial formating fixes. Bouncing these back to the submitter is time
consuming for the maintainer, adds latency, and can lead to patch
lossage.

In the case of a merge conflict, it's not actually possible with
mercurial to checkin the original patch and the fix. In the cases where
there has been other trivial changes, it seems quite heavy weight to
create a 2nd changeset: having unnecessary changesets causes unnecessary
xenrt validation runs, slows down binary-chop bug hunting, and
complicates back porting patches. 

My preferance would be to authorize maintainers to make 'simple'
modifications to patches before checkin as a single changset. Anything
more 'semantic' should be a second changest.

I fully agree that once we agree the finer points of the process we
should document it and stick to it religously. We need a "patch
submission process" document on the wiki.

Ian 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>