[lkml]   [2009]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.


 \ /
  Last update: 2009-03-18 18:19    [W:0.057 / U:0.408 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site