On Mon, Nov 19, 2012 at 08:59:33PM +0400, Michael Tokarev wrote:
> Hello.
>
> I'm trying to pick whatever fixes applicable for 1.1.x series of qemu
> and qemu-kvm. Since Michael Roth said he will not be releasing more
> 1.1.x series, I think I can at least try to do that. Qemu-1.1 will
> be included in upcoming Debian Wheezy release, so we're interested
> in keeping it stable.
>
> I've a git tree and a branch which I created for this purpose, available
> at http://git.corpit.ru/?p=qemu.git;a=shortlog;h=refs/heads/stable-1.1-queue
> (git://git.corpit.ru/qemu.git#stable-1.1-queue ) -- this is the patches
> I picked from upstream git tree which - in my opinion - are applicable
> for 1.1.x.
>
> Please take a look. This is the first time I'm trying to do something like
> that, and am not sure if that's okay or not. Also, if there are any other
> fixes missing in there but should be, please ping me (or qemu-stable@).
This is how I've done it in the past, but based on some discussions
we had at this year's QEMU Summit I think the consensus is that the
flow should be upstream -> qemu-sta...@nongnu.org -> stable releases.
I think it's inevitable that we'll end up wanting to pick up some patches
that aren't CC'd to qemu-stable, but the way I plan on handling that is
to CC qemu-stable on such patches as part of the initial staging process.
Now that we have volunteers for long-term 0.15 and 1.1 releases, along with
the N-1 short-term releases, I think adopting this approach across the
board will help spread the workload and get us better converge overall,
since we'd all be leveraging each others' internal bug trackers,
testing, and eyes, but it's a new thing for me so I guess we'll how it
goes.
Although, I guess this latter bit isn't much different than just sending
out a list of candidates during staging/testing like we already/plan to
do, so maybe that's already good enough. You lose some of the thread context,
but those patches are already committed so it's "take it or leave it" at
that point.
Either way should probably work out okay I'd imagine.
>
> I plan to send out notifications about each change included there, in
> order to confirm that's okay. References to any scripts that may help
> there are definitely welcome.
Would be really nice to have a way to cross-reference upstream commits
against submissions to qemu-stable. One idea mentioned at the summit was
for submitters/committers to include or roll-in "cc: qemu-stable" to
patches with qemu-stable on CC, or patches that had responders that CC'd
stable. That requires a good deal of buy-in to be leveraged reliably
though. My approach has been to just periodically search through git commit
logs for any commits matching subjects: from patches on qemu-stable that
I still have marked as outstanding. With the current flowrate to
qemu-stable this hasn't been too much in terms of overhead.
I do have a script that I've used with limited success in the past for
cases where you do find yourself filtering through upstream commits. It
basically takes `git log X..origin/master` output and comments
out/annotates commits that have already been applied or cherry-picked
(via cherry-pick -sx) into your branch. It also let's you manually
comment out/annotate commits you don't need, and the output can be piped
back through the script to pick up any new commits/cherry-picks to your
local branch along with your manually annotations.
It's less and less useful the futher downstream you are though. I'll paste
it below for reference though. Keep in mind I had some issues the last
time I tried to use it so be weary.
>
> There are quite a few more fixes I'd add, especially in the USB front,
> but this area received too much changes past 1.1 version, including
> switching to asyncronous processing, so backporting stuff appears to
> be quite a bit difficult.
>
> Also, there are a few important changes which were posted to list (with
> pull requests too), but has not been merged for quite a while. Again,
> if there are some tools to help tracking such patches (like, to notify
> me on `git remote update' that some patch has been applied), please
> mention it, -- I'm trying to find something in this area.
>
> The git branch mentioned above is somewhat volatile, ie, I can rebase
> it at any time, when it becomes clear that some patch/change in there
> is not applicable for stable series.
>
> Many of the fixes in there are applicable for 1.2.x stable release too,
> but since Michael said he will be doing that series, I'm not tracking
> these. I can help here as well, if there's a need.
Yup, I'll make sure to go through these for 1.2.2
>
> Thank you for your attention.
>
> /mjt
>
#!/bin/bash
usage() {
cat <<EOF
git log upstream/master | $0 [<from_commit>] [<to_commit> (default: HEAD)]
Annotates \`git log\` output from an upstream branch with information on
whether or not those patches have been applied with the specified commit
range in the current repo/dir (defaults to HEAD)
/backported downstream. Assumes
backported patches are applied with \`git cherry-pick -x ...\`.
EOF
}
downstream_log_path="/tmp/git-check-backport-downstream-log"
if [ "$1" == "-h" ]; then
usage
exit 0
fi
if [ $# -gt 0 ]; then
git log $1 >$downstream_log_path
else
git log >$downstream_log_path
fi
committed=0
while IFS='' read -r line; do
if grep "^#" <<< "$line" 1>/dev/null; then
echo "$line"
continue
fi
if grep "^commit [a-f0-9]\+" <<< "$line" 1>/dev/null; then
committed=0
commit=`awk '{print $2}' <<< "$line"`
if grep "^commit $commit" $downstream_log_path 1>/dev/null; then
committed=1
echo "# ALREADY COMMITTED"
elif grep "cherry picked from commit $commit" $downstream_log_path
1>/dev/null; then
committed=1
echo "# ALREADY COMMITTED (cherry picked)"
fi
fi
if [ $committed -eq 1 ]; then
echo "# $line"
else
echo "$line"
fi
done
