[linux-yocto] [PATCH 01/29] i2c / ACPI: Use 0 to indicate that device does not have interrupt assigned

[Paul Gortmaker]

[Cc trimmed of non-yocto folks to spare them the noise]

[Re: [linux-yocto] [PATCH 01/29] i2c / ACPI: Use 0 to indicate that device does not have interrupt assigned] On 08/02/2016 (Mon 09:13) Saul Wold wrote:

> On Sun, 2016-02-07 at 17:09 -0500, Paul Gortmaker wrote:
> > [[linux-yocto] [PATCH 01/29] i2c / ACPI: Use 0 to indicate that
> > device does not have interrupt assigned] On 05/02/2016 (Fri 06:53)
> > Saul Wold wrote:
> > 
> > > From: Mika Westerberg <mika.westerberg at linux.intel.com>
> > 
> > Normally here at this point it is nice to see:
> > 
> > commit dab472eb931bc2916fa779e56deccd0ec319cf5b upstream.
> > 
> > This is the convention used by all the stable kernel maintenance
> > trees.
> 
> Paul, Thanks!  This is the first kernel patch set I am sending,
> appreciate the feedback, I send patches elsewhere but the conventions
> are different.

Yeah, understood; I've got the unfair advantage of spending most of my
time wading around in the kernel and did one of the stable releases too.

I've got a script for automagically insterting the upstream commit at
the time of commit extraction.  A neat trick is that you can create
a script "git-myfeature" and put it in $PATH and then you can run it
from anywhere with "git myfeature" (no dash).  And it will even tab
complete the 2nd word for you...

> 
> I will break this series up and add the upstream note where I find
> them.
> 
> > It makes it much easier to decide when later that we can toss it
> > based
> > on moving to a new kernel version.  For example:
> > 
> > paul at yow-builder:~/git/linux-head$ git describe dab472eb931
> > v4.1-rc3-44-gdab472eb931b
> > 
> > ...so the commit was created on a 4.1-rc3 baseline, but...
> > 
> > paul at yow-builder:~/git/linux-head$ git describe --contains
> > dab472eb931
> > v4.2-rc1~158^2~28
> > 
> > ...not merged to mainline until 158 commits before the 4.2-rc1 tag
> > marked the end of the 4.2 development cycle.  So anything pre-4.2
> > will
> > need to carry this.
> > 
> > Normally I use some script to toss the output of the above two lines
> > into a comment above the commit in the scc file, which also eases the
> > carry forward load of bigger BSP patch series.
> > 
> Willing to share your script?

I'll attach it (and the extraction script above).  The script was meant
to pull out a whole linear series of commits for a series file (with the
ID iterator $i), and de-number them, but the documenting part essentially
boils down to:

 ----------------------------
        NP=`echo 0001-*patch`
        P=`echo $NP | sed 's/^0001-//'`

        XID=`git describe $i`

        # commits not yet under a tag are not contained yet.
        git describe --contains $i > /dev/null 2>&1
        if [ $? = 0 ]; then
                CID=`git describe --contains $i` 
        else
                CID="(on master)"
        fi
        echo "# $CID -- $XID" >> $PATCHDIR/series

        echo $P >> $PATCHDIR/series
        mv $NP $PATCHDIR/$P
        if [ $? != 0 ]; then
                echo \"mv $NP $PATCHDIR/$P\" failed, a name conflict?
                exit 1
        fi
 ----------------------------

For repos that don't use extensive use of tags that are somewhat linear
with time/development, the "--contains" info won't be as useful, but on
the kernel, I really like how it shows where it was merged as per above.

[...]

> > 
> > I wonder about the auto-Cc collection of mail addresses in the
> > linux-yocto case.  It might be a bit of a coin toss; but I'm leaning
> > towards leaving them off, esp. when the 0/N didn't include all the
> > ppl
> > to give them context.  Maintainers/authors probably get enough
> > revisit
> > spam from all the "official" stable trees, hence why I'd lean towards
> > leaving them out for other custom/forked projects like this.
> > 
> 
> I will ensure not to send to the Cc list in the future.

Yeah, I think that is probably best.  The "--suppress-cc=<category>"
cmdline option has several variations to tune it to suit.  For internal
use, we'd decided a blanket approach of $HOME/gitconfig having a:

[sendemail]
       suppresscc = all

was the only way to reliably stop developers from inadvertently spamming
the original developers when sharing patches around for backporting.
But I don't think you want that ; as you'll want proper Cc: creation for
patches to OE etc that are not kernel backports.

Paul.
-------------- next part --------------
#!/bin/bash
# Assume that $1 might be HEAD, or a tag, or an abbrev. ID.
GIT_ID=`git rev-parse $1`
if [ $? != 0 ]; then
	echo $1 doesnt appear to be a valid git ref
	exit -1
fi

TMPF=`mktemp`
git format-patch -p $1^..$1 > $TMPF 2>&1
if [ $? != 0 ]; then
	echo format-patch failed
	cat $TMPF
	rm -f $TMPF
	exit -1
fi

FILE=`cat $TMPF`
rm -f $TMPF
if [ ! -f "$FILE" ];then
	echo cant find patch file $FILE
	exit -1
fi

# echo Commit is $FILE

(
	echo '/^$/a'
	echo -e "commit $GIT_ID upstream.\n"
	echo .
	echo w
	echo q 
) | ed -s $FILE
-------------- next part --------------
#!/bin/bash

# mkseries [-p] <dirname> <startcommit> <stopcommit>

# make a series of patches in dirname for the above commit range
# [-p]   prefix word "patch" in series file for scc usage.

# assumes you have "git cextract" that inserts mainline commit ID.

if [ "$1" = "-p" ]; then
        SCC="patch"
        shift
fi

if [ -z "$1" ]; then
	echo need a directory name to dump patches into
	exit 1
fi
PATCHDIR=$1

if [ -z "$2" ]; then
	echo need a start commit
	exit 1
fi
START=$2

if [ -z "$3" ]; then
	echo need stop commit
	exit 1
fi
STOP=$3

if [ -d $PATCHDIR ]; then
	if [ -d $PATCHDIR~ ]; then
		echo Removing old backup $PATCHDIR~
		echo hit ^C to abort
		sleep 2
	fi
	rm -rf $PATCHDIR~
	mv $PATCHDIR $PATCHDIR~
fi
mkdir $PATCHDIR
if [ $? != 0 ]; then
	echo mkdir failed
	exit 1
fi

ls 0001-*patch > /dev/null 2>&1
if [ $? = 0 ]; then
	echo you have 0001-\*.patch files already, please move them
	exit 1
fi

git rev-parse $START > /dev/null 2>&1
if [ $? != 0 ]; then
        echo $START is not a valid commit to start from
        exit 1
fi

git rev-parse $STOP > /dev/null 2>&1
if [ $? != 0 ]; then
        echo $STOP is not a valid commit to stop at
        exit 1
fi

MC=`git rev-list --merges ^$START~ $STOP | wc -l`
if [ $MC != "0" ]; then
	echo Warning - your range contains $MC merge\(s\)
	echo you are probably not going to get what you want
	sleep 2
fi

for i in `git rev-list --topo-order --reverse --no-merges ^$START~ $STOP` ; do
	git cextract $i
	if [ $? != 0 ]; then
		echo extraction of $i failed
		exit 1
	fi

	NP=`echo 0001-*patch`
	P=`echo $NP | sed 's/^0001-//'`

	XID=`git describe $i`

	# commits not yet under a tag are not contained yet.
	git describe --contains $i > /dev/null 2>&1
	if [ $? = 0 ]; then
		CID=`git describe --contains $i` 
	else
		CID="(on master)"
	fi
	echo "# $CID -- $XID" >> $PATCHDIR/series

	echo $SCC $P >> $PATCHDIR/series
	mv $NP $PATCHDIR/$P
	if [ $? != 0 ]; then
		echo \"mv $NP $PATCHDIR/$P\" failed, a name conflict?
		exit 1
	fi
	echo $P
done