mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Daniel Dressler <danieru.dressler@gmail.com>
Cc: dsterba@suse.cz, Chris Mason <clm@fb.com>,
	Josef Bacik <jbacik@fb.com>,
	"open list:BTRFS FILE SYSTEM" <linux-btrfs@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Btrfs: disk-io: replace root args iff only fs_info used
Date: Sat, 22 Nov 2014 00:42:14 +0100	[thread overview]
Message-ID: <20141121234213.GG8568@twin.jikos.cz> (raw)
In-Reply-To: <CAGC3nLAUSy-dJGAzz2THDeX6UoSsbZ8BOWUb2pGRoVSWqQpZaw@mail.gmail.com>

On Sat, Nov 22, 2014 at 01:37:10AM +0900, Daniel Dressler wrote:
> What would a cover letter be like? Would that be a separate email to
> the list, or maybe the first email in a patch series?

It's a separate mail that does not carry any diff but an overview of
the following patches. The patches are threaded under that mail. This is
what the git command does for you:

  git format-patch -o output --thread --cover-letter from..to

and in the directory 'output' you'll find the cover letter plus patches.
The cover contains some stub and should be edited.  Then send them via
'git send-email'.

> Sorry I've twice looked for the integration repo. I found some that
> look like it could be but those had older commits. Could you direct me
> to the exact branch I'd love to work against it. These patches were
> done against linux-next.

The integration is in Chris' git, but the branch may not be the most
recent compared to Linus' tree or the pending for-linus branches. This
depens on the phase of the development cycle or the stability of the
patches in the integration branch as it's supposed to be base of the
next pull.

What you did is fine under current conditions. If the integration is
made public you can check if your patches are merged or not and then
refresh the patch series eventually.

> I think small one function patches might be best. I have the codebase
> mapped out and each file's functions-to-be-cleaned count varies
> wildly. If I did batch files together and split large files apart
> there would be no rhyme or reason for the groupings. With single
> function patches it is very clear what changes are justified since
> they should only occur in the affected function or in a call-site.
> With multiple functions the call-site changes get mixed up would it
> would be harder to review.

Up to you.

      parent reply	other threads:[~2014-11-21 23:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <danieru.dressler@gmail.com>
2014-11-21  8:15 ` Daniel Dressler
2014-11-21 16:15   ` David Sterba
2014-11-21 16:37     ` Daniel Dressler
2014-11-21 23:18       ` Duncan
2014-11-21 23:42       ` David Sterba [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=20141121234213.GG8568@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=clm@fb.com \
    --cc=danieru.dressler@gmail.com \
    --cc=jbacik@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®