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]

Date:	Sat, 7 Aug 2010 09:34:17 +0200
From:	Jens Axboe <jaxboe@...ionio.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] block/IO bits for 2.6.36-rc1

On 08/06/2010 05:51 PM, Linus Torvalds wrote:
> On Fri, Aug 6, 2010 at 8:44 AM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>>
>>                                                                    ... And
>> once you _do_ ask me to merge from you, I still don't want you to do
>> the merge, because I want to know about what conflicts. That's where
>> the bugs almost always are.
> 
> Actually, let me rephrase that.
> 
> Almost all bugs are just individual commits. But the "oh, we had
> conflicts between trees" is where the subtle bugs that are due to
> interactions between two different development projects tend to be..
> 
> So "almost always" is not really true - almost always bugs are just
> simply bugs: incorrect code. I wish we didn't have that, but hey,
> reality clearly hates me.  But the reason I want to see the merge
> problems (even if I then occasionally end up having to send it back
> and say "ok, I see the merge problem and I can't handle it, you do it
> for me") is because that way I _see_ when people step on each others
> feet. Because when it happens, it's ripe for nasty issues, including
> simply ones that are due to bad development habits, or due to bad
> source tree organization.

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.

This puts a lot of extra work on Stephen.

-- 
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.
--
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/