linux-kernel - Re: [GIT PULL] block/IO bits for 2.6.36-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTincMAv0OLYHSqHNwrhfKBC-yQHhgWdqKYHoJNOf@mail.gmail.com>
Date:	Sat, 7 Aug 2010 14:15:15 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jens Axboe <jaxboe@...ionio.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] block/IO bits for 2.6.36-rc1

On Sat, Aug 7, 2010 at 12:34 AM, Jens Axboe <jaxboe@...ionio.com> wrote:
>
> OK, so a question on this. Say a bug surfaces in the middle of the
> release and we push in a change to fix that at 2.6.36-rc3 time. This
> same patch will not apply directly to the branch holding 2.6.37 patches
> due to code reshuffling or whatnot. How do you want that handled? I
> can't pull in your branch and resolve it. The merge conflict may not be
> visible to you until 2.6.36 is released and I want to offload the
> patches to you, but it will be visible in linux-next pretty much
> immediately.

So I think there's a few possible answers to that.

One is the one I outlined in my previous email: merge the next -rc
tag, and explain why you merged it in the commit message. That not
only makes the merge commit message be way more informative ("Merge
commit v2.6.3x-rcy" rather than "Merge branch 'master'"), but it also
automatically acts as a "rate limiter" for the merges.

Now, that may cause problems for linux-next for a few days too, since
I think linux-next always starts from some random tree-of-the-day of
mine. That itself may be more indicative of a linux-next problem,
though. It might well make sense to base linux-next itself on the
latest tagged release rather than on some random daily thing (and if
the things that get merged _into_ linux-next then are based on a
random daily thing and bring linux-next forward, then that's a problem
with the trees getting merged - they shouldn't be doing that either).

The other possibility is for you to do throw-away merges just for
linux-next. That way _you_ do the merge (not Stephen or one of the
linux-next helpers), but the merge is going only into for-next, not
into your for-2.6.36 branch. "git rerere" will help you re-do the same
merge for future for-next trees - the same way linux-next already
generally only needs to do the merge resolution once.

Then, when you actually want to send it to me, at that point (if it's
a really complicated merge and you know it's too complex for me), you
can do one final merge into 'for-linus' before you send me the pull
request. Again, git rerere will help you re-use your previous merge
resolutions.

Or don't merge at all when you send it to me, and only do the merge if
I then reply with "ok, that's too complicated for me".

I will _never_ complain about you sending me something I can't merge.
I may throw it back at you, but I won't complain about you trying to
give me merge work.  I really do like knowing about the conflicts.

Of course, if I do the merge conflict resolution I may then see
something odd and complain about it. Something I might not have even
noticed if it hadn't been pointed out to me by the conflict ;)

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