Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1252783 > unrolled thread

Re: [PATCH v8 00/14] support "task_isolation" mode for nohz_full

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v8 00/14] support "task_isolation" mode for nohz_full Peter Zijlstra <peterz@infradead.org> - 2015-10-21 14:40 +0200
    Re: [PATCH v8 00/14] support "task_isolation" mode for nohz_full Chris Metcalf <cmetcalf@ezchip.com> - 2015-10-22 22:40 +0200
      Re: [PATCH v8 00/14] support "task_isolation" mode for nohz_full Frederic Weisbecker <fweisbec@gmail.com> - 2015-10-23 04:40 +0200
        Re: [PATCH v8 00/14] support "task_isolation" mode for nohz_full Peter Zijlstra <peterz@infradead.org> - 2015-10-23 11:00 +0200
          Re: [PATCH v8 00/14] support "task_isolation" mode for nohz_full Frederic Weisbecker <fweisbec@gmail.com> - 2015-10-23 15:30 +0200
      Re: [PATCH v8 00/14] support "task_isolation" mode for nohz_full Peter Zijlstra <peterz@infradead.org> - 2015-10-23 11:10 +0200
        Re: [PATCH v8 00/14] support "task_isolation" mode for nohz_full Theodore Ts'o <tytso@mit.edu> - 2015-10-23 14:00 +0200

#1252783 — Re: [PATCH v8 00/14] support "task_isolation" mode for nohz_full

Can you *please* start a new thread with each posting?

This is absolutely unmanageable.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1254165

On 10/21/2015 08:39 AM, Peter Zijlstra wrote:
> Can you *please* start a new thread with each posting?
>
> This is absolutely unmanageable.

I've been explicitly threading the multiple patch series on purpose
due to this text in "git help send-email":

        --in-reply-to=<identifier>
               Make the first mail (or all the mails with --no-thread) appear
               as a reply to the given Message-Id, which avoids breaking
               threads to provide a new patch series. The second and subsequent
               emails will be sent as replies according to the
               --[no]-chain-reply-to setting.

               So for example when --thread and --no-chain-reply-to are
               specified, the second and subsequent patches will be replies to
               the first one like in the illustration below where [PATCH v2
               0/3] is in reply to [PATCH 0/2]:

               [PATCH 0/2] Here is what I did...
                 [PATCH 1/2] Clean up and tests
                 [PATCH 2/2] Implementation
                 [PATCH v2 0/3] Here is a reroll
                   [PATCH v2 1/3] Clean up
                   [PATCH v2 2/3] New tests
                   [PATCH v2 3/3] Implementation

It sounds like this is exactly the behavior you are objecting
to.  It's all one to me because I am not seeing these emails
come up in some hugely nested fashion, but just viewing the
responses that I haven't yet triaged away.

So is your recommendation to avoid the git send-email --in-reply-to
option?  If so, would you recommend including an lkml.kernel.org
link in the cover letter pointing to the previous version, or
is there something else that would make your workflow better?

If you think this is actually the wrong thing, is it worth trying
to fix the git docs to deprecate this option?  Or is it more a question
of scale, and the 80-odd patches that I've posted so far just pushed
an otherwise good system into a more dysfunctional mode?  If so,
perhaps some text in Documentation/SubmittingPatches would be
helpful here.

-- 
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1254299

On Thu, Oct 22, 2015 at 04:31:44PM -0400, Chris Metcalf wrote:
> On 10/21/2015 08:39 AM, Peter Zijlstra wrote:
> >Can you *please* start a new thread with each posting?
> >
> >This is absolutely unmanageable.
> 
> I've been explicitly threading the multiple patch series on purpose
> due to this text in "git help send-email":
> 
>        --in-reply-to=<identifier>
>               Make the first mail (or all the mails with --no-thread) appear
>               as a reply to the given Message-Id, which avoids breaking
>               threads to provide a new patch series. The second and subsequent
>               emails will be sent as replies according to the
>               --[no]-chain-reply-to setting.
> 
>               So for example when --thread and --no-chain-reply-to are
>               specified, the second and subsequent patches will be replies to
>               the first one like in the illustration below where [PATCH v2
>               0/3] is in reply to [PATCH 0/2]:
> 
>               [PATCH 0/2] Here is what I did...
>                 [PATCH 1/2] Clean up and tests
>                 [PATCH 2/2] Implementation
>                 [PATCH v2 0/3] Here is a reroll
>                   [PATCH v2 1/3] Clean up
>                   [PATCH v2 2/3] New tests
>                   [PATCH v2 3/3] Implementation
> 
> It sounds like this is exactly the behavior you are objecting
> to.  It's all one to me because I am not seeing these emails
> come up in some hugely nested fashion, but just viewing the
> responses that I haven't yet triaged away.

I personally (and I think this is the general LKML behaviour) use in-reply-to
when I post a single patch that is a fix for a bug, or a small enhancement,
discussed on some thread. It works well as it fits the conversation inline.

But for anything that requires significant changes, namely a patchset,
and that includes a new version of such patchset, it's usually better
to create a new thread. Otherwise the thread becomes an infinite mess and it
eventually expands further the mail client columns.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1254406

On Fri, Oct 23, 2015 at 04:33:02AM +0200, Frederic Weisbecker wrote:
> On Thu, Oct 22, 2015 at 04:31:44PM -0400, Chris Metcalf wrote:
> > On 10/21/2015 08:39 AM, Peter Zijlstra wrote:
> > >Can you *please* start a new thread with each posting?
> > >
> > >This is absolutely unmanageable.
> > 
> > I've been explicitly threading the multiple patch series on purpose
> > due to this text in "git help send-email":
> > 
> >        --in-reply-to=<identifier>
> >               Make the first mail (or all the mails with --no-thread) appear
> >               as a reply to the given Message-Id, which avoids breaking
> >               threads to provide a new patch series. The second and subsequent
> >               emails will be sent as replies according to the
> >               --[no]-chain-reply-to setting.
> > 
> >               So for example when --thread and --no-chain-reply-to are
> >               specified, the second and subsequent patches will be replies to
> >               the first one like in the illustration below where [PATCH v2
> >               0/3] is in reply to [PATCH 0/2]:
> > 
> >               [PATCH 0/2] Here is what I did...
> >                 [PATCH 1/2] Clean up and tests
> >                 [PATCH 2/2] Implementation
> >                 [PATCH v2 0/3] Here is a reroll
> >                   [PATCH v2 1/3] Clean up
> >                   [PATCH v2 2/3] New tests
> >                   [PATCH v2 3/3] Implementation
> > 
> > It sounds like this is exactly the behavior you are objecting
> > to.  It's all one to me because I am not seeing these emails
> > come up in some hugely nested fashion, but just viewing the
> > responses that I haven't yet triaged away.

Yeah, the git people are not per definition following lkml standards,
even though git originated 'here'. They, for a long time, also defaulted
to --chain-reply-to, which is absolutely insane.

> I personally (and I think this is the general LKML behaviour) use in-reply-to
> when I post a single patch that is a fix for a bug, or a small enhancement,
> discussed on some thread. It works well as it fits the conversation inline.
> 
> But for anything that requires significant changes, namely a patchset,
> and that includes a new version of such patchset, it's usually better
> to create a new thread. Otherwise the thread becomes an infinite mess and it
> eventually expands further the mail client columns.

Agreed, although for single patches I use my regular mailer (mutt) and
can't be arsed with tools. Also I don't actually use git-send-email
ever, so I might be biased.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1254597

On Fri, Oct 23, 2015 at 10:49:51AM +0200, Peter Zijlstra wrote:
> On Fri, Oct 23, 2015 at 04:33:02AM +0200, Frederic Weisbecker wrote:
> > I personally (and I think this is the general LKML behaviour) use in-reply-to
> > when I post a single patch that is a fix for a bug, or a small enhancement,
> > discussed on some thread. It works well as it fits the conversation inline.
> > 
> > But for anything that requires significant changes, namely a patchset,
> > and that includes a new version of such patchset, it's usually better
> > to create a new thread. Otherwise the thread becomes an infinite mess and it
> > eventually expands further the mail client columns.
> 
> Agreed, although for single patches I use my regular mailer (mutt) and
> can't be arsed with tools.

Yeah me too, otherwise I can't write a text before the patch changelog.

> Also I don't actually use git-send-email ever, so I might be biased.

Ah it's just too convenient so I wrote my scripts on top of it :-)
But surely many mail sender libraries can post patches just fine as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1254410

On Thu, Oct 22, 2015 at 04:31:44PM -0400, Chris Metcalf wrote:

> So is your recommendation to avoid the git send-email --in-reply-to
> option?  If so, would you recommend including an lkml.kernel.org
> link in the cover letter pointing to the previous version, or
> is there something else that would make your workflow better?

Mostly people don't bother with pointing to previous versions, and if
they have the same 0/x subject, they're typically trivial to find
anyway.

But if you really feel the need for explicit references to previous
versions, then yes, lkml.kernel.org/r/ links are preferred over pretty
much anything else I think.

> If you think this is actually the wrong thing, is it worth trying
> to fix the git docs to deprecate this option?

As said in the other email; git has different standards than lkml. By
now we're just one of many many users of git.

> Or is it more a question
> of scale, and the 80-odd patches that I've posted so far just pushed
> an otherwise good system into a more dysfunctional mode?  If so,
> perhaps some text in Documentation/SubmittingPatches would be
> helpful here.

Documentation/email-clients.txt maybe.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1254516

On Fri, Oct 23, 2015 at 11:04:59AM +0200, Peter Zijlstra wrote:
> > If you think this is actually the wrong thing, is it worth trying
> > to fix the git docs to deprecate this option?
> 
> As said in the other email; git has different standards than lkml. By
> now we're just one of many many users of git.

Even git developers will create a new thread for a large (more than
2-3 patches) patch set.  However, for a single patch, people have
chained the -v3 version of the draft --- not to the v2 version,
though, but to the review of the patch.  And I've seen that behavior
on some LKML lists, and I'm certainly fine with it on linux-ext4.

But if you have a huge patch series, and you keep chaining it unto the
8th, 10th, 22nd version, it certainly will get **very** annoying for
some MUA's.

The bottom line is that you should use common sense, and it can be
hard to document every last bit of what should be "common sense" into
a rule that is followed by robots or a perl script.  (Which is one of
the reasons why I'm not fond of the philosophy that every single last
checkpatch warning or error should result in a "cleanup" patch, but
that's another issue.)

Cheers,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web