Re: [Xen-devel] [PATCH v3] Add TRACKING.IMPORTS to xen.git to more easily manage imported files that need to be kept in sync with an upstream

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

On 21/06/2019, 07:14, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:

    >>> On 20.06.19 at 16:18, <lars.kurth@xxxxxxxxxx> wrote:
    > On 27/05/2019, 10:41, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
    > 
    >     >>> On 24.05.19 at 19:44, <lars.kurth@xxxxxxxxxx> wrote:
    >     > Following the recent discussion, we had on IRC and the action I had 
in 
    >     > the March community call, this file provides a file format that 
    >     > enables writing an automated test to check whether files are out of 
sync. 
    >     > 
    >     > An example, what file content may look like is embedded below
    >     > repo: linux-torvalds git 
    >     > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
    >     > file: xen/drivers/passthrough/arm/smmu.c linux-torvalds 
    >     > linux/drivers/iommu/arm-smmu.c b77cf11f094136
    >     > 
    >     > Once the file format is agree, I will write a test or script.
    >     > 
    >     > I also need some more correct test data, aka entries in the file 
from
    >     > committers looking after the following files
    >     > [Jan]
    >     > xen/arch/x86/cpu/mwait-idle.c 
    >     > [Stefano, Julien - this has to be finalized]
    >     > xen/drivers/passthrough/arm/smmu.c
    >     > xen/arch/arm/vgic/*
    >     > xen/include/asm-arm/div64.h
    >     > xen/drivers/char/meson-uart.c
    >     > xen/arch/arm/arm32/lib/*
    >     > xen/arch/arm/arm64/lib/*
    >     > xen/arch/arm/arm64/cache.S
    >     > xen/arch/arm/arm64/bpi.S
    >     > xen/include/asm-arm/system.h
    >     > xen/arch/arm/arm64/insn.c
    >     > [Others?]
    >     > xen/common/rbtree.c
    >     > 
    >     > Note that in some cases Linux has diverged and some Linux files 
have disappeared. 
    >     > Julien also raised the point, that in some cases only a subset of 
code from 
    >     > Linux Xen files was applied or that only some functions get moved 
across to 
    >     > Xen.
    >     > 
    >     > I believe that is entirely OK. The workflow would be in most cases 
that:
    >     > - We use a Linux (source) commit as a benchmark and record the 
commit ID
    >     > - If there is a change in Linux the test will fail
    >     > - The committer looks at the diff and either
    >     >   - Decides to ignore it and bumps the commit ID in this file
    >     >   - Decides the change is needed, integrates it into Xen and then 
    >     >     bumps the commit ID in this file
    >     
    >     With this ...
    >     
    >     > Changes since v1
    >     > * Require a colon after repo:, file:, ... keywords
    >     > * Replace manual:|auto: with file: as there auto: use-case was 
invalid
    >     > * Added more verbose description of format
    >     > 
    >     > Changes since v2
    >     > * Changed some formatting
    >     > * Removed examples
    >     > * Removed references to https
    >     
    >     ... move past the first --- separator ...
    >     
    >     > Signed-off-by: Lars Kurth <lars.kurth@xxxxxxxxxx>
    >     
    >     Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
    >     
    > Are any extra ACKs needed?  
    
    I don't think there's a strict requirement for more, but I think it
    would be nice to at least get whoever brought up the tracking
    idea to acknowledge that this approach is likely going to fit.
    Unless of course it was yourself to bring this up first ...
    
It was brought up in a community call in February and you, Julien, George, Paul 
Durrant and Stefano all felt this was a good idea. 
But there was no specific requestor
The trigger of the discussion was a post-mortem of 4.12 (and the ARGO patches) .

Regards
Lars
    
    

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel