linux-kernel - Re: [GIT PATCH] block: cleanup patches, take#2

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 18 Mar 2009 18:17:11 +0100
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	axboe@...nel.dk, linux-kernel@...r.kernel.org
Subject: Re: [GIT PATCH] block: cleanup patches, take#2

On Tuesday 17 March 2009, Tejun Heo wrote:
> Hello, Bartlomiej.
> 
> Bartlomiej Zolnierkiewicz wrote:
> > Patches look fine but 0002-0003 will cause pata/block merge conflicts
> > for linux-next once they go into block tree so no ACK from me for this
> > approach.
> > 
> > $ patch -p1 --dry-run < 0002.patch
> > patching file drivers/ide/ide-disk.c
> > Hunk #1 FAILED at 405.
> > 1 out of 1 hunk FAILED -- saving rejects to file drivers/ide/ide-disk.c.rej
> > patching file drivers/ide/ide-ioctls.c
> > 
> > $ patch -p1 --dry-run < 0003.patch
> > patching file drivers/ide/ide-cd.c
> > Reversed (or previously applied) patch detected!  Assume -R? [n]
> 
> Heh... for some reason, I think Stephen wouldn't have much problem
> merging those conflicts.

Well, you can just ask Stephen if he is fine with fixing merge conflicts
for a week or so.  If he agrees fine with me.  I just wouldn't like to see
the _whole_ tree dropped from linux-next because of the last moment block
_cleanup_ patches.

> I was hoping to push this patchset into 2.6.30.  The thing is that if
> you only want to take changes from -linus and don't want to provide
> git trees, your tree is kind of blocked from both sides except around
> -rc1 window, so if there are multiple related changesets, they either
> have to go in one after another during a -rc1 window or they need to
> be split over multiple -rc1 windows, either of which isn't gonna work
> very well.
> 
> Please note that this isn't exactly some overhead which is unduly
> weighed on you.  Mid-layer or inter-related API changes often incur
> merge conflicts and things get very difficult unless there's some
> level of cooperation among related trees.
> 
> I understand that you're constrained time and resource-wise and will
> be happy to make things easier on your side but options are severely
> limited if you don't want to take any changes other than from
> upstream.  It would be best if you can maintain IDE changes in a git
> tree.  All that you lose are petty controls over change history.  The
> tree might look less tidy but it makes things much easier when
> multiple trees are involved.  I'll be happy to provide merge commits

I have been planning on quilt -> git conversion of pata-2.6 tree for some
time now but these merge conflicts happen very seldom (once in 6-12 months)
while the transition period would require quite a lot of time and work...

Anyway point taken.

> between blk and ide at sync points, so that you can pull from them and
> don't have to worry about conflicts.  I don't really think it will add
> a lot to your workload.
> 
> That said, let's postpone this patchset post -rc1 window and see how
> things can be worked out then.  Hmmm... I'll move the IDE patches on
> top of linux-next/pata-2.6 with other IDE patches.

Please do and thanks for understanding.

I think that we can deal with the rest of patches without a problem in the
second week of the merge window so everything will be nicely sorted out by
the time of -rc1.

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