From: Dave Chinner <david@fromorbit.com>
To: Ben Myers <bpm@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: [patch v4 00/13] xfs: remove the xfssyncd mess
Date: Sat, 6 Oct 2012 11:31:22 +1000 [thread overview]
Message-ID: <20121006013122.GF23644@dastard> (raw)
In-Reply-To: <20121005171853.985930109@sgi.com>
On Fri, Oct 05, 2012 at 12:18:53PM -0500, Ben Myers wrote:
> Hi Dave,
>
> Here I am reposting your xfssyncd series. I want to make sure that
> we're all on the same page. In particular, are we all happy with patch
> 6, 'xfs: xfs_sync_data is redundant'?
>
> Version 4:
> - updated 'xfs: xfs_sync_data is redundant' with cleanups to the
> xfs_flush_inodes interface as per Christoph's request,
> - updated 'xfs: xfs_sync_data is redundant', folding in changes from
> http://oss.sgi.com/archives/xfs/2012-10/msg00036.html
> - fixed a minor typo in xfs: 'syncd workqueue is no more', renaming the
> log worker from 'xfs-reclaim' to 'xfs-log'.
>
> I was going to rush this in for the 3.7 merge window. However in the
> light of the issues with patch 6 and Linus's comment here:
> http://lkml.org/lkml/2012/9/30/152 and Stephen's comment here:
> https://lkml.org/lkml/2012/9/23/144, I think it wiser to behave. 3.7
> is stable without this series, so I will merge it for 3.8.
>
> Once we have an agreement that patch 6 is ready I will pull this in to the
> master branch first thing after the 3.7-rc1 merge from upstream.
<sigh>
Seriously? Why am I only finding out that there needs to be more
rework to patches in this series after someone else reposted them?
And that this is the cause of it missing the merge window?
So, a week ago on IRC I said to you (Ben):
[27/09/12 09:42] <dchinner_> I'm not really surprised you missed me
[27/09/12 09:42] <dchinner_> in fact, that's what I wanted to talk about
[27/09/12 09:43] <dchinner_> I'm getting really frustrated by the 24-hour turnaround time for any sort of discussion with you and mark
[27/09/12 09:44] <dchinner_> You and mark only seem to respond to the mailing list in Eagan business hours (roughly 10am-4:30pm according to the time stamps on your emails)
[27/09/12 09:44] <dchinner_> and that corresponds pretty closely with the 7-8 hours I sleep every night.
[27/09/12 09:45] <dchinner_> I tend to check and respond to mailing list traffic over a 15-16 window each day, but even doing that I get zero overlap with your online times.
[27/09/12 09:45] <dchinner_> So discussions that should take an hour or 2 and be solved take a week or more
[27/09/12 09:49] <dchinner_> I can't lengthen my day any more than it already is to try to get some overlap with you and Mark....
[27/09/12 11:16] * dchinner_ suspects he's going to be waiting until tomorrow to get a response....
If I was frustrated by this communication problem a week ago....
If you simply said that there's more than just folding a fix into
the series, I could have done all the changes and had it turned
around in about 2 hours (modification, build and test cycle time),
and all these issues could have been shaken out several days ago.
If the first I hear that there is significant rework needed to one
of my patchsets is someone else reposting it with changes that need
discussion in it, then there's a serious comminucation breakdown
occurring.
Seriously, if there's more than one less-than-trivial problem with a
patch set, through it back to the owner of the patchset to fix. The
maintainers job is to communicate and co-ordinate, not fix other
people's patch sets for them. It just doesn't scale - push problems
back to the patch owner to deal with.
FWIW, I'll quote from another patchset description I posted yesterday
(allocation workqueue deadlock fixes) to point out that I'm not just
commenting on this patch set:
"This is a followup from the last conversation with Mark about this
deadlock. I haven't heard anything in the last couple of days, so I
figured I'd just write the patches that did what I thought is
needed."
The discussion of that patch series made 4-5 round trips between
Mark and myself over a period of more than 2 weeks, with me always
waiting on answers from Mark so that I could understand the problem
he was seeing and trying to fix. Realistically, it should have taken
2-3 days at most. And then when I don't get a response for 2-3 days
in the middle of a working week, I'm left to wonder WTF is going on.
I end up just doing the change instead of letting it get dropped on
the ground, without knowing whether I'm duplicating work that is
already being done by someone else.
As I said, I can't do any more than I already do to try to get lower
latency and more frequent communications, so there's little I can do
to reduce the amount of frustration I'm having. So I'm reduced to
making more public noise about the problem in the hope that we can
come up with a solution....
Not a happy camper.
-Dave
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-10-06 1:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-05 17:18 [patch v4 00/13] xfs: remove the xfssyncd mess Ben Myers
2012-10-05 17:18 ` [patch v4 01/13] [PATCH 01/13] xfs: xfs_syncd_stop must die Ben Myers
2012-10-05 17:18 ` [patch v4 02/13] [PATCH 02/13] xfs: rationalise xfs_mount_wq users Ben Myers
2012-10-05 17:18 ` [patch v4 03/13] [PATCH 03/13] xfs: dont run the sync work if the filesystem is Ben Myers
2012-10-05 17:18 ` [patch v4 04/13] [PATCH 04/13] xfs: sync work is now only periodic log work Ben Myers
2012-10-05 18:16 ` Christoph Hellwig
2012-10-05 18:31 ` Mark Tinguely
2012-10-05 17:18 ` [patch v4 05/13] [PATCH 05/13] xfs: Bring some sanity to log unmounting Ben Myers
2012-10-05 17:18 ` [patch v4 06/13] [PATCH 06/13] xfs: xfs_sync_data is redundant Ben Myers
2012-10-05 17:55 ` Mark Tinguely
2012-10-05 18:04 ` Ben Myers
2012-10-05 18:15 ` Christoph Hellwig
2012-10-05 18:15 ` Mark Tinguely
2012-10-05 17:19 ` [patch v4 07/13] [PATCH 07/13] xfs: syncd workqueue is no more Ben Myers
2012-10-05 17:59 ` Mark Tinguely
2012-10-05 17:19 ` [patch v4 08/13] [PATCH 08/13] xfs: xfs_sync_fsdata is redundant Ben Myers
2012-10-05 17:19 ` [patch v4 09/13] [PATCH 09/13] xfs: move xfs_quiesce_attr() into xfs_super.c Ben Myers
2012-10-05 17:19 ` [patch v4 10/13] [PATCH 10/13] xfs: xfs_quiesce_attr() should quiesce the log like Ben Myers
2012-10-05 17:19 ` [patch v4 11/13] [PATCH 11/13] xfs: rename xfs_sync.[ch] to xfs_icache.[ch] Ben Myers
2012-10-05 17:19 ` [patch v4 12/13] [PATCH 12/13] xfs: move inode locking functions to xfs_inode.c Ben Myers
2012-10-05 17:19 ` [patch v4 13/13] [PATCH 13/13] xfs: remove xfs_iget.c Ben Myers
2012-10-06 1:31 ` Dave Chinner [this message]
2012-10-06 17:37 ` [patch v4 00/13] xfs: remove the xfssyncd mess Ben Myers
2012-10-08 0:33 ` Dave Chinner
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=20121006013122.GF23644@dastard \
--to=david@fromorbit.com \
--cc=bpm@sgi.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