XFS Sprints

XFS Sprints

[Darrick J. Wong]

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

Re: XFS Sprints

[Carlos Maiolino]

Hi Darrick.

On Wed, Sep 15, 2021 at 07:36:52PM -0700, Darrick J. Wong wrote:
> Hi again,
> 
> 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.

Not to mention cases when reviews come 'too late'. A V2 is submitted right
before a new comment on V1, and that creates a V3,4,5....
> 
> 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.
> 
> 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.

Despite the fact I particularly don't like the term 'sprint' :) I believe
gathering together from time to time to discuss next steps, is much appreciated.
My experience with the past few years is mostly what you described, everything
is scattered and it's hard to know what to prioritize. At a first I was mostly
thinking it was due my TZ constrains, which usually brings me 'late to the
party' (if I arrive at all :). But with your email, it seems there are more
things in play.
Lately I've been trying to help mostly on reviews, but again, it's usually hard
to know what to review first, so, most of time I feel like randomly picking
stuff on the list to review, unless somebody asks for help reviewing something
specific. So, from a reviewing PoV, this can help a lot what should be reviewed
first.
Also, probably now mostly regarding my TZ, I'm usually oblivious regarding
what's happening, so, I sometimes have a hard time to figure out where I can
give a hand when I have some spare time, maybe these 'meetings' (or whatever
we'll call it) will also help in this case.

Regarding on 'where', may I suggest a single email thread per -rc (or week,
month, whatever)? I'm just being selfish here though, so I don't need to be
on irc late night or early morning :) But if email doesn't work, I'll do what I
can to attend the meetings.

Cheers.

-- 
Carlos

Re: [External] : XFS Sprints

[Chandan Babu R]

On 16 Sep 2021 at 08:06, 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.)
>

Apart from patchsets associated with implementing new features, small changes
and bug fixes for an upcoming kernel release, may be we should also allow
developers to post RFC patchsets to obtain an initial high-level feedback
for a design that implements a fairly complicated new feature?

-- 
chandan

Re: [External] : XFS Sprints

[Carlos Maiolino]

On Thu, Sep 16, 2021 at 05:54:03PM +0530, Chandan Babu R wrote:
> > 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.)
> >
> 
> Apart from patchsets associated with implementing new features, small changes
> and bug fixes for an upcoming kernel release, may be we should also allow
> developers to post RFC patchsets to obtain an initial high-level feedback
> for a design that implements a fairly complicated new feature?

Hmm, AFAIK, this has never been a problem, just check the list, there are
several [RFC PATCH] patches around. Not sure if maybe you're talking about
something more specific?

-- 
Carlos

Re: XFS Sprints

[Eric Sandeen]

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
>