[Linux-HA] More thoughts about 2.1.1 - SCHEDULE CHANGE - 23 July,
2007
Andrew Beekhof
beekhof at gmail.com
Fri Jul 13 10:56:06 MDT 2007
And attaching the script would probably be helpful...
On 7/13/07, Andrew Beekhof <beekhof at gmail.com> wrote:
>
> I thoroughly agree with what you are proposing.
>
> You may find the attached script (my own work) useful for cherry-picking
> patches from one mercurial repo to another.
>
>
> In particular, it preserves the log, timestamp and author which is useful
> when trawling through changesets at a later date. It uses this information
> to detects when changesets have already been applied and skips them.
>
>
> Basic usage for importing patches from 'dev' into 'test' is:
>
>
> # cd test
> # hgpatch ../dev
>
>
> Although I encourage the use of --blacklist <filename> so that you are not
> re-prompted to apply skipped patches next time.
>
>
> Oh, and it probably requires bash.
>
>
>
> On 7/13/07, Alan Robertson <alanr at unix.sh> wrote:
> >
> > Hi,
> >
> > I have a few things to say here, and a change of mind, which I'll
> > explain in more detail.
> >
> > First, I appreciate the work that Andrew and Dejan and Dave and others
> > have gone to to get us what looks like a really solid release. Awesome
> > work guys!
> >
> > Second, I want to apologize for not fully understanding what Mercurial
> > can do for us in better managing our releases. My lack of gut-level
> > understanding (which is now hopefully mostly past) led me to follow the
> > procedures we'd used in the past - which worked out OK, but weren't
> > optimal. In addition, I want to thank Andrew for prodding me into using
> > Mercurial the way it was meant to be used. Now I get it.
> >
> > As a result, I now have some freedom in putting out the release which I
> > didn't have pre-Mercurial, because there is no need for a code freeze at
> >
> > all. In spite of "getting it" there is still a bit of a learning curve
> > to go through here, in terms of how to get more community involvement,
> > and so on. No doubt I'm not not done with learning. I reserve the
> > right to get smarter.
> >
> > Some people are concerned that we haven't put enough effort into testing
> > this release, and are don't have as much confidence as I think they
> > should in this process. Rather than arguing that I know what I'm doing
> > (which I think I do), I'd rather just delay the release, and put in some
> > more testing, and shore up that confidence through more testing, and
> > more opportunity for others to do testing.
> >
> > To accommodate this, I've decided to delay the release for one week.
> > The official release date for 2.1.1 is now 23 July, 2007.
> >
> > You can get the latest source for this release here:
> > http://hg.linux-ha.org/test/archive/tip.tar.bz2
> > or here http://hg.linux-ha.org/test/archive/tip.tar.gz
> > You can see the patches and so on in this release here:
> > http://hg.linux-ha.org/test/
> >
> > Here are the proposed rules of engagement for this one week period:
> > - Each additional changeset will have a bugzilla for it, and will be
> > linked to by the bugzilla, and the changeset on 'dev'
> > will link to the bugzilla entry.
> > - Every proposed bug fix will be announced on the -dev mailing list
> > - Every proposed changeset will be inspected by myself and the
> > community before being accepted.
> > - Each accepted changeset will be announced on the -dev list
> > right after it has been pushed to the 'test' repository
> > - I have final authority on whether a given fix will go in
> > during this time.
> >
> > Here are some of the criteria I will use to decide if a fix will go in:
> > - Does it fix a regression?
> > Fixes that fix regressions will be given priority
> > - Does it fix something that would cause data damage?
> > Fixes that fix data damage will be given high priority.
> > - Is the patch "obviously harmless"? - like a documentation
> > or release description change, or comments, or similar.
> > - Will it require starting our long-running tests over?
> > Things which will require this will likely have to wait for
> > the next release, unless they are likely to destroy data.
> > - Is it something that our long-running CTS tests don't test for?
> > If so, then we won't have to start tests over.
> > For example, if it's a *BSD-only fix, or a GUI fix, and
> > if it's early enough to get reasonable manual testing, then
> > I may take it.
> >
> > These are not exhaustive, but indicative of the criteria I will use.
> >
> > If we find too many regressions or probable data damage fixes (which is
> > unlikely), then we would likely have to delay the release.
> >
> > --
> > Alan Robertson <alanr at unix.sh >
> >
> > "Openness is the foundation and preservative of friendship... Let me
> > claim from you at all times your undisguised opinions." - William
> > Wilberforce
> > _______________________________________________
> > Linux-HA mailing list
> > Linux-HA at lists.linux-ha.org
> > http://lists.linux-ha.org/mailman/listinfo/linux-ha
> > See also: http://linux-ha.org/ReportingProblems
> >
>
>
>
-------------- next part --------------
function hg_patch_menu() {
source_repo=$1
changeset=$2
blacklist=$3
echo -n "Apply patch $changeset? (yes|no|log|diff|diffstat) [no] "
read do_patch
done=0
case "$do_patch" in
Y|y|Yes|yes|YES)
hg -R $source_repo export $changeset > $changeset.patch
hg import $changeset.patch
rc=$?
if [ $rc != 0 ]; then
echo "Hg import failed: $rc"
return $rc
fi
rm $changeset.patch
new_id=`hg id | awk '{print $1}'`
if [ "$new_id" != "$changeset" ]; then
echo Imported $changeset as $new_id
fi
done=1
;;
log)
hg -R $source_repo log -r $changeset
;;
diffstat)
hg -R $source_repo log -r $changeset -p | diffstat
;;
patch|diff)
hg -R $source_repo log -r $changeset -p
;;
n|N|NO|No|no|"")
if [ "x$blacklist" != "x" ]; then
echo "Blacklisting changeset $changeset in $blacklist"
echo "$changeset `date`" >> $blacklist
fi
done=1
;;
*) echo "Unknown response: '$do_patch'";;
esac
if [ $done = 0 ]; then
hg_patch_menu $source_repo $changeset $blacklist
fi
return 0
}
function hgpatch() {
done=0
verbose=0
while test "$done" = "0"; do
case "$1" in
-v) verbose=1; shift;;
--skip) skip_until=$2; shift; shift;;
--blacklist) cs_blacklist=$2; shift; shift;;
--list) cs_list=$2; shift; shift;;
"") done=1;;
*) source_repo="$1"; shift;;
esac
done
if [ "x$source_repo" = "x" ]; then
echo "Usage $0 [--skip until_patch] [--blacklist file] source_repo"
return
fi
echo "Reading blacklist from $cs_blacklist..."
if [ "x" = "x$cs_list" ]; then
echo "Retrieving list of patches..."
PATCHES=`hg in -M $source_repo | grep changeset: | tr ':' ' ' | awk '{print $4}' | tr '\n' ' '`
else
PATCHES=$cs_list
fi
num_patches=`echo $PATCHES | wc -w`
echo Processing $num_patches patches
fuzz_limit=`expr $num_patches + 100`
hg_id=`hg id`
if [ "x$hg_id" = "x$skip_until" ]; then
skip_until=""
fi
for change in $PATCHES; do
rc=0
do_patch=1
shortlog=`hg log -R $source_repo -r $change -M --template "{author|email}\t{desc|firstline|strip} On: {date|date}\n"`
if [ "x$skip_until" != "x" ]; then
do_patch=0
if [ "x$change" = "x$skip_until" ]; then
skip_until=""
echo "Found change root..."
else
echo "Skipping $change..."
fi
elif [ "x$cs_blacklist" != "x" ]; then
grep $change $cs_blacklist &> /dev/null
if [ $? = 0 ]; then
echo "- Patch $change is blacklisted: $shortlog"
do_patch=0
fi
fi
if [ $do_patch = 1 ]; then
# Search based on shortlog output
match=`hg log -l $fuzz_limit -M --template "CS: {node|short}. Patch by {author|email}\t{desc|firstline|strip} On: {date|date})\n" | /usr/bin/grep -F "$shortlog"`
if [ $? = 0 ]; then
echo "+ Patch $change previously applied as: $match"
do_patch=0
fi
fi
if [ $do_patch = 1 ]; then
echo ""
hg -R $source_repo log -r $change
hg_patch_menu $source_repo $change $cs_blacklist
rc=$?
echo ""
fi
if [ $rc != 0 ]; then
echo "Aborted"
break
fi
done
}
More information about the Linux-HA
mailing list