From: Tejun Heo <tj@kernel.org>
To: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Cc: axboe@kernel.dk, linux-kernel@vger.kernel.org
Subject: Re: [GIT PATCH] block: cleanup patches, take#2
Date: Tue, 17 Mar 2009 09:10:12 +0900 [thread overview]
Message-ID: <49BEEA64.6060607@kernel.org> (raw)
In-Reply-To: <200903161853.14268.bzolnier@gmail.com>
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.
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
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.
Jens, please keep reviewing. I'll keep track of ack status.
Thanks.
--
tejun
next prev parent reply other threads:[~2009-03-17 0:10 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-16 2:28 [GIT PATCH] block: cleanup patches, take#2 Tejun Heo
2009-03-16 2:28 ` [PATCH 01/17] ide: use blk_run_queue() instead of blk_start_queueing() Tejun Heo
2009-03-16 2:28 ` [PATCH 02/17] ide: don't set REQ_SOFTBARRIER Tejun Heo
2009-03-16 2:28 ` [PATCH 03/17] ide: use blk_update_request() instead of blk_end_request_callback() Tejun Heo
2009-03-16 2:28 ` [PATCH 04/17] block: merge blk_invoke_request_fn() into __blk_run_queue() Tejun Heo
2009-03-16 2:28 ` [PATCH 05/17] block: kill blk_start_queueing() Tejun Heo
2009-03-16 2:28 ` [PATCH 06/17] block: don't set REQ_NOMERGE unnecessarily Tejun Heo
2009-03-16 2:28 ` [PATCH 07/17] block: cleanup REQ_SOFTBARRIER usages Tejun Heo
2009-03-16 2:28 ` [PATCH 08/17] block: clean up misc stuff after block layer timeout conversion Tejun Heo
2009-03-16 2:28 ` [PATCH 09/17] block: reorder request completion functions Tejun Heo
2009-03-16 2:28 ` [PATCH 10/17] block: reorganize request fetching functions Tejun Heo
2009-03-16 2:28 ` [PATCH 11/17] block: kill blk_end_request_callback() Tejun Heo
2009-03-16 2:28 ` [PATCH 12/17] block: clean up request completion API Tejun Heo
2009-03-16 2:28 ` [PATCH 13/17] block: move rq->start_time initialization to blk_rq_init() Tejun Heo
2009-03-16 2:28 ` [PATCH 14/17] block: implement and use [__]blk_end_request_all() Tejun Heo
2009-03-16 2:28 ` [PATCH 15/17] block: kill end_request() Tejun Heo
2009-03-16 3:23 ` Grant Likely
2009-03-16 3:27 ` Grant Likely
2009-03-21 2:58 ` Tejun Heo
2009-03-24 11:37 ` Jens Axboe
2009-03-24 13:07 ` Tejun Heo
2009-03-16 2:28 ` [PATCH 16/17] ubd: simplify block request completion Tejun Heo
2009-03-16 2:29 ` [PATCH 17/17] block: clean up unnecessary stuff from block drivers Tejun Heo
2009-03-16 17:53 ` [GIT PATCH] block: cleanup patches, take#2 Bartlomiej Zolnierkiewicz
2009-03-17 0:10 ` Tejun Heo [this message]
2009-03-18 17:17 ` Bartlomiej Zolnierkiewicz
2009-03-19 0:19 ` Tejun Heo
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=49BEEA64.6060607@kernel.org \
--to=tj@kernel.org \
--cc=axboe@kernel.dk \
--cc=bzolnier@gmail.com \
--cc=linux-kernel@vger.kernel.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