linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: "Darrick J. Wong" <djwong@kernel.org>,
	Allison Henderson <allison.henderson@oracle.com>,
	Brian Foster <bfoster@redhat.com>,
	Catherine Hoang <catherine.hoang@oracle.com>,
	Dave Chinner <david@fromorbit.com>,
	Eryu Guan <guaneryu@gmail.com>,
	Gao Xiang <hsiangkao@linux.alibaba.com>,
	Christoph Hellwig <hch@infradead.org>,
	Chandan Babu R <chandanrlinux@gmail.com>,
	Eric Sandeen <sandeen@redhat.com>,
	Matthew Wilcox <willy@infradead.org>,
	Bill O'Donnell <billodo@redhat.com>,
	Shiyang Ruan <ruansy.fnst@fujitsu.com>
Cc: xfs <linux-xfs@vger.kernel.org>
Subject: Re: XFS Sprints
Date: Wed, 22 Sep 2021 09:01:30 -0500	[thread overview]
Message-ID: <3475534f-dd71-978a-0690-f54b5631a9d7@sandeen.net> (raw)
In-Reply-To: <20210916023652.GA34820@magnolia>

Hi Darrick -

Just wanted to chime in with my support for this approach - both the
more collaborative concept, and the planning specifics. And I think
those will go hand in hand. If specific goals (patchsets) are agreed on
for a release, it will be easier for people to focus and help get those
goals accomplished.

Thanks for thinking about this and proposing a plan. It might take a
little time to shift behaviors and expectations, but I think this is
totally worth a shot.

Thanks,
-Eric

On 9/15/21 9:36 PM, Darrick J. Wong wrote:
> Hi again,
> 
> Now that 5.15-rc1 is past, I would like to say something:
> 
> I've been reflecting on my (sharply higher) stress levels in 2021, and
> realized that I don't enjoy our development process anymore.  One of the
> nice things about being a co-maintainer is that I can take advantage of
> the fact that suggesting improvements == leadership, though that comes
> with the responsibility that leadership == actually making it happen.
> 
> The thing that has been bothering me these past few months is how we
> decide what's going into the next merge window.  People send patchsets
> at various points between the second week of the merge window and the
> week after -rc6, and then ... they wait to see if anyone will actually
> read them.  I or one of the maintainers will get to them eventually, but
> as a developer it's hard to know if nobody's responding because they
> don't like the patchset?  Or they're quietly on leave?  Or they're
> drowning trying to get their own patchsets out to the list?  Or they
> have too many bugs to triage and distro kernel backports?  Or they're
> afraid of me?
> 
> Regardless, I've had the experience that it's stressful as the
> maintainer looking at all the stuff needing review; it's stressful as a
> developer trying to figure out if I'm /really/ going to make any
> progress this cycle; and as a reviewer it's stressful keeping up with
> both of these dynamics.  I've also heard similar sentiments from
> everyone else.
> 
> The other problem I sense we're having is implied sole ownership of
> patchesets being developed.  Reviewers make comments, but then it seems
> like it's totally on the developer (as the applicant) to make all those
> changes.  It's ... frustrating to watch new code stall because reviewers
> ask for cleanups and code restructuring that are outside of the original
> scope of the series as a condition for adding a Reviewed-by tag... but
> then they don't work on those cleanups.
> 
> At that point, what's a developer to do?  Try to get someone else's
> attention and start the review process all over again?  Try to get
> another maintainer's attention and have them do it?  This last thing is
> hard if you're already a maintainer, because doing that slows /everyone/
> down.
> 
> (And yes, I've been growing our XFS team at Oracle this year so that
> this doesn't seem so one-sided with RedHat.)
> 
> I've also heard from a few of you who find it offputting when patches
> show up with verbiage that could be interpreted as "I know best and
> won't take any further suggestions".  I agree with your feelings when
> I hear complaints coming in, because my own thoughts had usually already
> been "hmm, this sounds preemptively defensive, why?"
> 
> Ok, so, things I /do/ like:
> 
> During the 5.15 development cycle I really enjoyed going back and forth
> with Dave over my deferred inode inactivation series and the log
> speedups that we were both proposing.  I learned about percpu lists, and
> I hope he found it useful to remember how that part of the inode cache
> works again.  This dialectic was what drew me to XFS back in 2014 when I
> started working on reflink, and I've been missing it, especially since
> the pandemic started.
> 
> So the question I have is: Can we do community sprints?  Let's get
> together (on the lists, or irc, wherever) the week after -rc2 drops to
> figure out who thinks they're close to submitting patchsets, decide
> which one or two big patchsets we as a group want to try to land this
> cycle, and then let's /all/ collaborate on making it happen.  If you
> think a cleanup would be a big help for someone else's patchset, write
> those changes and make that part happen.
> 
> There's never been a prohibition on us working like that, but I'd like
> it if we were more intentional about working like a coordinated team to
> get things done.  What do you all think?
> 
> (Small changes and bug fixes can be sent any time and I'll take a look
> at them; I'm not proposing any changes to that part of the process.)
> 
> --D
> 

      parent reply	other threads:[~2021-09-22 14:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-16  2:36 Darrick J. Wong
2021-09-16  9:50 ` Carlos Maiolino
2021-09-16 12:24 ` [External] : " Chandan Babu R
2021-09-16 13:18   ` Carlos Maiolino
2021-09-22 14:01 ` Eric Sandeen [this message]

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=3475534f-dd71-978a-0690-f54b5631a9d7@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=allison.henderson@oracle.com \
    --cc=bfoster@redhat.com \
    --cc=billodo@redhat.com \
    --cc=catherine.hoang@oracle.com \
    --cc=chandanrlinux@gmail.com \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=guaneryu@gmail.com \
    --cc=hch@infradead.org \
    --cc=hsiangkao@linux.alibaba.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=ruansy.fnst@fujitsu.com \
    --cc=sandeen@redhat.com \
    --cc=willy@infradead.org \
    --subject='Re: XFS Sprints' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).