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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox