[Top] [All Lists]

Re: [PATCH 01/18] xfstests: Remove obsolete remake script

To: Philip White <pwhite@xxxxxxx>
Subject: Re: [PATCH 01/18] xfstests: Remove obsolete remake script
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 15 Mar 2013 13:12:34 +1100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130314130611.405A853DEAEF@xxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <20130314130611.405A853DEAEF@xxxxxxxxxxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Mar 14, 2013 at 06:06:11AM -0700, Philip White wrote:
> From: Phil White <pwhite@xxxxxxx>
> This is a rebasing & resubmit of a dchinner patch.  His comments on the
> original:
> -----------------
> We don't ever do wholesale rebuilds of the output files anymore, so
> kill the script that does it to reduce the dependency on common and
> common.rc.
> -----------------
> Signed-off-by: Phil White <pwhite@xxxxxxx>

Hi Phil - it's great that you've picked this up, but it would have
been really nice to know that you were doing this. Just a short
email on the list with me CC'd or even just a private message on
IRC. Last I heard from anyone at SGI was that SGI still didn't want
to remove the old bench scripts. Now I find out that you've picked
up the patchset that removes it and forward ported it....

If you let me know you were doing this, I could have let you know
that my local version has several more patches in it and bug fixes
that I haven't posted out. Indeed, I coul dhave taken an hour to
apply all the changes to the most recent additions to xfstests and
posted an up-to-date version, because I've been maintaining the
patchset locally.

Indeed, one of my test VMs runs this version of xfstests all the

$ sudo MKFS_OPTIONS="-b size=512" ./check -g auto
FSTYP         -- xfs (debug)
PLATFORM      -- Linux/x86_64 test-1 3.9.0-rc2-dgc+
MKFS_OPTIONS  -- -f -b size=512 /dev/vdb
MOUNT_OPTIONS -- /dev/vdb /mnt/scratch

generic/001      2s
generic/002      0s
generic/005      0s

So I could have saved you a lot of work if you'd simply told us that
SGI had decided that "dropping bench is OK". If you make a decision
like this, then please tell us when you make it - sometimes it will
save you a lot of unnecessary time and effort....

/me knows what his afternoon is going to be spent doing: updating
all the recent tests added to xfstests and posting a current patch


For future reference for everyone, a few technical guidelines for
reposting patch sets written by other people.  This is important to
get right, as we all know that the correct attribution of the
original of the code has legal significance.

- when you are reposting a mostly unmodified patch written by
  someone else, you should not claim it as your own, nor strip off
  the original s-o-b lines. i.e. reposted patches should have a
  description that looks like:

From: Dave Chinner <dchinner@xxxxxxxxxx>

<unmodified original patch description>

<[pwhite] modifications added (if any) during rebasing>

Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Signed-off-by: Phil White <pwhite@xxxxxxx>

  See the way I have done this in the CRC patchset attributing
  various patches in the series to Christoph and how I've modified
  them from Christoph's original versions. e.g:


  This is especially important if the patches contain copyright
  title updates - they can only be made by the author of the code in
  question. Hence if the patch is listed as "from X" and the
  copyright statement says "(c) Y." then that is a big problem...

- comments like "this is a rebasing and resubmit" don't belong in
  commit messages, they belong in the patch 0 description.  Patch 0
  should also contain a high level description of the patch set and
  outline the changes you've made to the original code.

- large patch series need to be correctly threaded with a patch 0
  describing the series. git-send-email should be able to do this
  for you automatically.

- rebasing a patch set to a current tree means you need to apply all
  the changes to new files that have been added since this patch set
  was originally written. Part of rebasing is "making new stuff
  work"... ;)


Dave Chinner

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