From: Dave Chinner <david@fromorbit.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH] fs: gfs2: Adding new return type vm_fault_t
Date: Tue, 17 Apr 2018 12:08:52 +1000 [thread overview]
Message-ID: <20180417020852.GI5572@dastard> (raw)
In-Reply-To: <CAFqt6zYQ=M89gRFK2TOS+nm-3XG+9BJxZ7ckXw5zC=n3adSn5g@mail.gmail.com>
On Mon, Apr 16, 2018 at 11:20:59PM +0530, Souptick Joarder wrote:
> > Hi,
> >
> > This patch is straightforward enough, but there are a lot of other
> > file systems that need similar patches. Shouldn't you do one big
> > patch set that fixes several file systems at once and run it through
> > Viro's kernel or Linus's kernel or something?
> > Adding Viro and linux-fsdevel for more opinions.
>
> The plan for these patches is to introduce the typedef, initially just
> as documentation ("These functions should return a VM_FAULT_ status").
> We'll trickle the patches to individual drivers/filesystems in through
> the maintainers, as far as possible. Then we'll change the typedef to
> an unsigned int and break the compilation of any unconverted
> drivers/filesystems.
>
> We have already started sending out drivers/filesystems changes
> to different maintainers.
Yes, we can see that. The response you are getting is "this is not
how we do cross-subsystem API changes. Why are you doing it this
way?"
i.e. the problem being pointed out is that your process has not
followed the correct/normal process for proposing, reviewing and
mering cross-subsystem API changes. Bob has raised the same
questions as both Christoph and Darrick have asked in response to
the XFS patch. I only implied these questions by asking about
introducing useless typedefs with no context for reviewers...
I'd really like to have Darrick's questions answered(*) in a
constructive, non-abusive manner - I'll quote it here to get it all
in one thread on -fsdevel:
| ...hm, the original mm patch wasn't cc'd to fsdevel either, so that's
| probably why I never heard of any of this until now.
|
| So, uh, why wasn't this whole series (all the mm changes and all the
| required fs changes) sent out for review prior to the merge window?
We're not asking for a description of what you are doing - we are
asking why the normal processes for proposing and merging such a
change is not being followed, and how you plan to rectify that.
Cheers,
Dave.
https://marc.info/?l=linux-xfs&m=152389824107375&w=2
--
Dave Chinner
david at fromorbit.com
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Souptick Joarder <jrdr.linux@gmail.com>
Cc: Bob Peterson <rpeterso@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
swhiteho@redhat.com, cluster-devel@redhat.com,
Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH] fs: gfs2: Adding new return type vm_fault_t
Date: Tue, 17 Apr 2018 12:08:52 +1000 [thread overview]
Message-ID: <20180417020852.GI5572@dastard> (raw)
In-Reply-To: <CAFqt6zYQ=M89gRFK2TOS+nm-3XG+9BJxZ7ckXw5zC=n3adSn5g@mail.gmail.com>
On Mon, Apr 16, 2018 at 11:20:59PM +0530, Souptick Joarder wrote:
> > Hi,
> >
> > This patch is straightforward enough, but there are a lot of other
> > file systems that need similar patches. Shouldn't you do one big
> > patch set that fixes several file systems at once and run it through
> > Viro's kernel or Linus's kernel or something?
> > Adding Viro and linux-fsdevel for more opinions.
>
> The plan for these patches is to introduce the typedef, initially just
> as documentation ("These functions should return a VM_FAULT_ status").
> We'll trickle the patches to individual drivers/filesystems in through
> the maintainers, as far as possible. Then we'll change the typedef to
> an unsigned int and break the compilation of any unconverted
> drivers/filesystems.
>
> We have already started sending out drivers/filesystems changes
> to different maintainers.
Yes, we can see that. The response you are getting is "this is not
how we do cross-subsystem API changes. Why are you doing it this
way?"
i.e. the problem being pointed out is that your process has not
followed the correct/normal process for proposing, reviewing and
mering cross-subsystem API changes. Bob has raised the same
questions as both Christoph and Darrick have asked in response to
the XFS patch. I only implied these questions by asking about
introducing useless typedefs with no context for reviewers...
I'd really like to have Darrick's questions answered(*) in a
constructive, non-abusive manner - I'll quote it here to get it all
in one thread on -fsdevel:
| ...hm, the original mm patch wasn't cc'd to fsdevel either, so that's
| probably why I never heard of any of this until now.
|
| So, uh, why wasn't this whole series (all the mm changes and all the
| required fs changes) sent out for review prior to the merge window?
We're not asking for a description of what you are doing - we are
asking why the normal processes for proposing and merging such a
change is not being followed, and how you plan to rectify that.
Cheers,
Dave.
https://marc.info/?l=linux-xfs&m=152389824107375&w=2
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2018-04-17 2:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-14 19:41 [Cluster-devel] [PATCH] fs: gfs2: Adding new return type vm_fault_t Souptick Joarder
2018-04-16 16:58 ` Bob Peterson
2018-04-16 16:58 ` Bob Peterson
2018-04-16 17:50 ` [Cluster-devel] " Souptick Joarder
2018-04-16 17:50 ` Souptick Joarder
2018-04-17 2:08 ` Dave Chinner [this message]
2018-04-17 2:08 ` Dave Chinner
-- strict thread matches above, loose matches on Subject: below --
2018-07-02 16:46 [Cluster-devel] " Souptick Joarder
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=20180417020852.GI5572@dastard \
--to=david@fromorbit.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.