All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
Cc: Dave Chinner <david@fromorbit.com>,
	Christoph Hellwig <hch@infradead.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sasha Levin <alexander.levin@microsoft.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
Date: Mon, 2 Sep 2019 00:38:03 -0700	[thread overview]
Message-ID: <20190902073803.GB18988@infradead.org> (raw)
In-Reply-To: <389078.1567379634@turing-police>

On Sun, Sep 01, 2019 at 07:13:54PM -0400, Valdis Klētnieks wrote:
> Any recommendations on how to approach that?   Clone the current fs/fat code
> and develop on top of that, or create a branch of it and on occasion do the
> merging needed to track further fs/fat development?
> 
> Mostly asking for workflow suggestions - what's known to work well for this
> sort of situation, where we know we won't be merging until we have several
> thousand lines of new code?  And any "don't do <this> or you'll regret it
> later" advice is also appreciated. :)

Just try to hack it in in your local tree and see if it works at all.
Normally you should have a feeling of where this is heading at this
point and start iterating.  One it looks somewhat presentable send it
out to the list and ask for comments.

  reply	other threads:[~2019-09-02  7:38 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-30 16:42 [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat Valdis Klētnieks
2019-08-30 16:45 ` Christoph Hellwig
2019-08-31  0:48   ` Valdis Klētnieks
2019-08-31  6:46     ` Christoph Hellwig
2019-08-31 10:25       ` Valdis Klētnieks
2019-08-31 14:24         ` Andy Shevchenko
2019-08-31 14:51           ` Valdis Klētnieks
2019-09-01  1:07         ` Dave Chinner
2019-09-01  1:37           ` Gao Xiang
2019-09-01  3:05             ` Al Viro
2019-09-01  3:26               ` Gao Xiang
2019-09-01  3:37           ` Valdis Klētnieks
2019-09-01 22:43             ` Dave Chinner
2019-09-01 23:13               ` Valdis Klētnieks
2019-09-02  7:38                 ` Christoph Hellwig [this message]
2019-09-02  7:35         ` Christoph Hellwig
2019-09-02 15:25           ` Greg Kroah-Hartman
2019-09-02 19:00             ` Valdis Klētnieks
2019-09-02 19:06               ` Greg Kroah-Hartman
2019-09-08 10:50                 ` OGAWA Hirofumi

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=20190902073803.GB18988@infradead.org \
    --to=hch@infradead.org \
    --cc=alexander.levin@microsoft.com \
    --cc=david@fromorbit.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=valdis.kletnieks@vt.edu \
    /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.