From: Ben Myers <bpm@sgi.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 00/14 V5]: xfs: remove the xfssyncd mess
Date: Tue, 16 Oct 2012 13:19:45 -0500 [thread overview]
Message-ID: <20121016181945.GB1377@sgi.com> (raw)
In-Reply-To: <20121011050314.GA2739@dastard>
Hey Dave,
On Thu, Oct 11, 2012 at 04:03:15PM +1100, Dave Chinner wrote:
> On Wed, Oct 10, 2012 at 09:31:55PM -0500, Ben Myers wrote:
> > On Mon, Oct 08, 2012 at 05:39:21PM -0500, Ben Myers wrote:
> > > On Mon, Oct 08, 2012 at 09:55:58PM +1100, Dave Chinner wrote:
> > > > Hopefully the final version.
> > >
> > > I am testing this new rev now... My v4 run over the weekend crashed but
> > > unfortunately I wasn't able to get a stack trace. We'll see what shakes out.
> >
> > I'm still not sure what happened with the v4 run I mentioned. Subsequent
> > testing has shown this series to be solid with the new changes. It is ready to
> > go.
> >
> > However, pulling this in right now will result in a merge commit from the
> > upstream tree to ours later in the rc1 merge. My understanding is that if
> > Linus were to subsequently pull from our tree, the merge commit would cause
> > some ugliness in upstream commit history. See:
> >
> > http://oss.sgi.com/archives/xfs/2009-04/msg00014.html
>
>
> I'm not sure that's relevant. The problem ther was this sort of
> behaviour:
>
> - merge mainline into XFS tree.
> - commit XFS stuff
> - merge mainline into XFS tree
> - commit XFS stuff
> .....
> - merge mainline into XFS tree
> - commit XFS stuff
> - pull request
> - merge mainline into XFS tree
> - commit XFS stuff
> <loop>
>
> And so the changes in the XFS tree where not easy to discern from
> the changes pull in from mainline. Indeed, look at the pull request
> to see exactly waht Linus was complaining about:
>
> http://oss.sgi.com/archives/xfs/2009-04/msg00009.html
>
> Felix Blyakher (25):
> Merge branch 'master' of git+ssh://oss.sgi.com/oss/git/xfs/xfs
> [XFS] Warn on transaction in flight on read-only remount
> Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6
> Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6
> Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6
> xfs: Update maintainers
> Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6
> Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs
> Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs
> Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6
> Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs
> Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6
> Revert "[XFS] use scalable vmap API"
> Revert "[XFS] remove old vmap cache"
> Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6
> Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6
> Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6
> Fix xfs debug build breakage by pushing xfs_error.h after
> Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6
> Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs
> Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6
> xfs: increase the maximum number of supported ACL entries
> Merge branch 'master' of git://git.kernel.org/.../torvalds/ linux-2.6
> Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs
> Revert "xfs: increase the maximum number of supported ACL entries"
>
> This is the mess that Linus was complaining about - not about a
> single merge per release that is used to keep the tree tracking
> mainlinei having a conflict in it.
Yowza. That is ugly.
> Having a dev tree history something like:
>
> - commit XFS stuff
> - commit XFS stuff
> - merge -rc1 from mainline
> - commit XFS stuff
> - commit XFS stuff
> - commit XFS stuff
> ......
> - commit XFS stuff
> - pull request
> - commit XFS stuff
> - commit XFS stuff
> <loop per release>
>
> Isn't really the problem that Linus was talking about. Indeed, one
> mainline merge per release is pretty much as expected, especially if
> you have a tree that you do not rebase that is consistently
> committed to....
I see what you mean. The current situation where we always fast-forward to
-rc1 is still much cleaner than that in terms of history. The problem could
also be solved with a topic branch for the duration of the merge window.
There is some more insteresting discussion here:
http://lwn.net/Articles/328438/
I'll quote from Linus's email:
"And, in fact, preferably you don't pull my tree at ALL, since nothing
in my tree should be relevant to the development work _you_ do."
If we can abide by that by using topic branches instead of pulling work into
the master branch during the merge window I think it would be clearer in terms
of history. I'd really like to sync up on -rc1 without making a mess each
time. More topic branches would probably be good for us anyway. Maybe that is
something we can experiment with.
This link was also kind of interesting reading:
http://yarchive.net/comp/linux/git_merges_from_upstream.html
> > I haven't found a way around this, so that's why we're waiting until after the
> > -rc1 fast-forward to pull this in.
>
> Merges by themselves aren't bad - it's excessive, unnecessary
> use of them that causes problems. :/
Yep, I gather that I misunderstood the issue with that pull request.
Thanks,
Ben
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-10-16 18:18 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-08 10:55 [PATCH 00/14 V5]: xfs: remove the xfssyncd mess Dave Chinner
2012-10-08 10:55 ` [PATCH 01/14] xfs: xfs_syncd_stop must die Dave Chinner
2012-10-08 10:56 ` [PATCH 02/14] xfs: rationalise xfs_mount_wq users Dave Chinner
2012-10-08 10:56 ` [PATCH 03/14] xfs: don't run the sync work if the filesystem is read-only Dave Chinner
2012-10-08 10:56 ` [PATCH 04/14] xfs: sync work is now only periodic log work Dave Chinner
2012-10-08 10:56 ` [PATCH 05/14] xfs: Bring some sanity to log unmounting Dave Chinner
2012-10-08 10:56 ` [PATCH 06/14] xfs: xfs_sync_data is redundant Dave Chinner
2012-10-09 21:01 ` Ben Myers
2012-10-09 21:28 ` Dave Chinner
2012-10-09 21:41 ` Ben Myers
2012-10-09 22:23 ` Brian Foster
2012-10-09 22:54 ` Dave Chinner
2012-10-08 10:56 ` [PATCH 07/14] xfs: syncd workqueue is no more Dave Chinner
2012-10-08 10:56 ` [PATCH 08/14] xfs: xfs_sync_fsdata is redundant Dave Chinner
2012-10-08 10:56 ` [PATCH 09/14] xfs: move xfs_quiesce_attr() into xfs_super.c Dave Chinner
2012-10-08 10:56 ` [PATCH 10/14] xfs: xfs_quiesce_attr() should quiesce the log like unmount Dave Chinner
2012-10-08 10:56 ` [PATCH 11/14] xfs: rename xfs_sync.[ch] to xfs_icache.[ch] Dave Chinner
2012-10-08 10:56 ` [PATCH 12/14] xfs: move inode locking functions to xfs_inode.c Dave Chinner
2012-10-08 10:56 ` [PATCH 13/14] xfs: remove xfs_iget.c Dave Chinner
2012-10-08 10:56 ` [PATCH 14/14] xfs: only update the last_sync_lsn when a transaction completes Dave Chinner
2012-10-10 14:28 ` Ben Myers
2012-10-10 22:57 ` Dave Chinner
2012-10-08 22:39 ` [PATCH 00/14 V5]: xfs: remove the xfssyncd mess Ben Myers
2012-10-11 2:31 ` Ben Myers
2012-10-11 5:03 ` Dave Chinner
2012-10-16 18:19 ` Ben Myers [this message]
2012-10-10 21:33 ` Christoph Hellwig
2012-10-11 1:51 ` Ben Myers
2012-10-16 19:19 ` Ben Myers
2012-10-17 19:24 ` Ben Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121016181945.GB1377@sgi.com \
--to=bpm@sgi.com \
--cc=david@fromorbit.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.