From: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>,
Kari Argillander <kari.argillander@gmail.com>
Cc: "ntfs3@lists.linux.dev" <ntfs3@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH v3 0/9] fs/ntfs3: Use new mount api and change some opts
Date: Wed, 8 Sep 2021 13:32:59 +0300 [thread overview]
Message-ID: <c62ee307-d2ca-a3b5-ceea-fd8afa1b2bf8@paragon-software.com> (raw)
In-Reply-To: <CAHp75VetzFedGyqaB5TmsBH5UjBYpR8rimGmt8scn5fZ4FRbqg@mail.gmail.com>
On 08.09.2021 12:00, Andy Shevchenko wrote:
> On Tue, Sep 7, 2021 at 11:47 PM Kari Argillander
> <kari.argillander@gmail.com> wrote:
>> On Tuesday, September 7, 2021, Andy Shevchenko
>> (andy.shevchenko@gmail.com) wrote:
>>> On Tuesday, September 7, 2021, Konstantin Komarov <almaz.alexandrovich@paragon-software.com> wrote:
>>>> On 07.09.2021 10:36, Kari Argillander wrote:
>
> ...
>
>>>> Yes, everything else seems good.
>>>> We tested patches locally - no regression was
>>>
>>> The formal answer in such case should also contain the Tested-by tag. I would suggest you to read the Submitting Patches document (available in the Linux kernel source tree).
>>
>> He is a maintainer so he can add tags when he picks this up.
>
> It's a good practice to do so. Moreover, it's better to do it
> patch-by-patch, so tools like `b4` can cope with tags for *anybody*
> who will use it in automated way.
>
>> This is not
>> really relevant here.
>
> Why not?
>
>> Yes it should be good to include that but I have already
>> sended v4 which he has not tested. So I really cannot put this tag for him.
>> So at the end he really should not even put it here.
>
> For v4 I agree with you.
My answer doesn't contain Tested-by tag because author of patch already said
that there will be next version of patch.
Thanks for Submitting Patches document suggestion.
>
>> Also usually the maintainers will always make their own tests and usually
>> they will not even bother with a tested-by tag.
>
> If it's their own code, yes, if it's others', why not? See above as well.
>
>> Or do you say to me that I
>> should go read Submitting Patches document as I'm the one who submit
>> this?
>
> It's always good to refresh memory, so why not? :-)
>
prev parent reply other threads:[~2021-09-08 10:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-29 9:56 [PATCH v3 0/9] fs/ntfs3: Use new mount api and change some opts Kari Argillander
2021-08-29 9:56 ` [PATCH v3 1/9] fs/ntfs3: Remove unnecesarry mount option noatime Kari Argillander
2021-08-29 9:56 ` [PATCH v3 2/9] fs/ntfs3: Remove unnecesarry remount flag handling Kari Argillander
2021-08-29 9:56 ` [PATCH v3 3/9] fs/ntfs3: Convert mount options to pointer in sbi Kari Argillander
2021-08-29 9:56 ` [PATCH v3 4/9] fs/ntfs3: Use new api for mounting Kari Argillander
2021-08-29 9:56 ` [PATCH v3 5/9] fs/ntfs3: Init spi more in init_fs_context than fill_super Kari Argillander
2021-08-29 9:56 ` [PATCH v3 6/9] fs/ntfs3: Make mount option nohidden more universal Kari Argillander
2021-08-29 9:56 ` [PATCH v3 7/9] fs/ntfs3: Add iocharset= mount option as alias for nls= Kari Argillander
2021-08-29 9:56 ` [PATCH v3 8/9] fs/ntfs3: Rename mount option no_acl_rules > (no)acl_rules Kari Argillander
2021-08-29 10:16 ` Pali Rohár
2021-08-29 11:49 ` Kari Argillander
2021-08-29 9:56 ` [PATCH v3 9/9] fs/ntfs3: Show uid/gid always in show_options() Kari Argillander
2021-08-29 10:36 ` Pali Rohár
2021-09-07 7:36 ` [PATCH v3 0/9] fs/ntfs3: Use new mount api and change some opts Kari Argillander
2021-09-07 16:14 ` Konstantin Komarov
[not found] ` <CAHp75Vd==Dm1s=WK9p2q3iEBSHxN-1spHmmtZ21eRNoqyJ5v=Q@mail.gmail.com>
2021-09-07 20:47 ` Kari Argillander
2021-09-08 9:00 ` Andy Shevchenko
2021-09-08 10:32 ` Konstantin Komarov [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=c62ee307-d2ca-a3b5-ceea-fd8afa1b2bf8@paragon-software.com \
--to=almaz.alexandrovich@paragon-software.com \
--cc=andy.shevchenko@gmail.com \
--cc=kari.argillander@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ntfs3@lists.linux.dev \
/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