linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <jaxboe@fusionio.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] block/IO bits for 2.6.36-rc1
Date: Sun, 8 Aug 2010 06:54:07 -0400	[thread overview]
Message-ID: <4C5E8CCF.4020809@fusionio.com> (raw)
In-Reply-To: <AANLkTi=KkPhw8nA9PmQ7D8atKjTYXVCixUt=FHHNMy+S@mail.gmail.com>

On 08/07/2010 05:00 PM, Linus Torvalds wrote:
> On Sat, Aug 7, 2010 at 12:31 AM, Jens Axboe <jaxboe@fusionio.com> wrote:
>>
>> Sometimes urgent patches will sit in for-linus and then I will merge
>> those in to for-2.6.36 to save Stephen the hassle of carrying conflict
>> update patches.
> 
> The merges I saw weren't even urgent, because you had never actually
> pushed them to me as such for the previous release. So both sides of
> the merge was "for-2.3.36" as far as I can tell. That's what makes me
> think there's some odd duplication of branches with no point (except
> to make the history look ugly).

No, the for-2.6.36 -> for-next was nothing urgent, just me being too
eager updating for-next. Those should never have been merges.

> Now, don't get me wrong - I _like_ branches. I love it when people
> maintain different branches for different features, and then merge
> them together in order for me to pull them (or just ask me to pull
> multiple branches). See for example merge commit  415cb47998 that
> Pekka did to create one single thing for me to pull when he had
> maintained four different topic branches. Or see the x86 "tip" pulls
> from Ingo, Thomas and Peter as an example of just asking me to pull
> multiple branches separately.

I will likely take the same approach that Pekka did, at least if there
are merge issues before sending it out.

[snip lots of good info]

>> But if you don't like that way of doing things, I will stop and just
>> keep for-2.6.X+1 patches in a branch that is based off 2.6.X and never
>> updated. I will try that for the next release and see how that goes.
> 
> It's worth trying. In fact, it might be worth trying having a few
> different branches, especially since there has been several clearly
> different development threads for the block layer. It would be
> _beautiful_ if you were to send me a couple of different pull requests
> for things like "fix writeback" and "update cfs", and they'd be
> independent. Because I think they really _are_ independent things.

Yes, there tends to be several indepent topics of development in there.
Core block bits, io scheduler, writeback, splice, driver updates, etc. I
will clearly separate them. I think the biggest part of the problem is
that it earlier was just core block and IO scheduler, but it evolved
into something more. And my current approach just doesn't work for that,
since it's gotten progressively worse over the last 2-3 releases.

> But see above. Merges per se are not evil or bad. But thoughtless
> merges are bad (and quite frankly, I don't mind a _couple_ of
> unnecessary merges. It's when I see the daily kind that I go "no,
> there's something seriously wrong here". So none of this is about hard
> rules that have to be followed 100%, it's more flexible than that).
> 
> Give it a try,

Will do :-)

-- 
Jens Axboe


Confidentiality Notice: This e-mail message, its contents and any attachments to it are confidential to the intended recipient, and may contain information that is privileged and/or exempt from disclosure under applicable law. If you are not the intended recipient, please immediately notify the sender and destroy the original e-mail message and any attachments (and any copies that may have been made) from your system or otherwise. Any unauthorized use, copying, disclosure or distribution of this information is strictly prohibited.

      reply	other threads:[~2010-08-08 10:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-06 10:38 [GIT PULL] block/IO bits for 2.6.36-rc1 Jens Axboe
2010-08-06 10:42 ` Jens Axboe
2010-08-06 15:44 ` Linus Torvalds
2010-08-06 15:51   ` Linus Torvalds
2010-08-07  7:34     ` Jens Axboe
2010-08-07 21:15       ` Linus Torvalds
2010-08-08 11:00         ` Jens Axboe
2010-08-16 20:48         ` David Woodhouse
2010-08-07  7:31   ` Jens Axboe
2010-08-07 21:00     ` Linus Torvalds
2010-08-08 10:54       ` Jens Axboe [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=4C5E8CCF.4020809@fusionio.com \
    --to=jaxboe@fusionio.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).