Message-ID: <20130905092536.44dbe86a@endymion.delvare>
Date:	Thu, 5 Sep 2013 09:25:36 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: linux-next: rebase of the jdelvare-hwmon quilt series

Hi Stephen,

On Thu, 5 Sep 2013 10:19:03 +1000, Stephen Rothwell wrote:
> Why did you bother rebasing the jdelvare-hwmon quilt series?  None of the
> patches changed (not that that even matters).

I'm not "rebasing". Rebasing is a git thing, and I'm using quilt, not
git, to feed linux-next. Until the patches hit Linus' tree, I am not
maintaining a tree, I am maintaining a patch set on top of a moving
tree. I only use git to send my pull request to Linus to make things
easier for him.

What you see is just how quilt works. That's nothing to worry about.
I've been working that way for over 6 years. I am curious why you
started yelling at me about this 3 months ago when it has proven to
work just fine for 6 years. You asked me to tag what my quilt series
was based on, and I did. You asked me to get my patches in linux-next
ASAP so that they get more testing, and I do.

Last time, you mentioned a problem with testing results being lost when
I "rebase" my quilt series". I don't quite think it's true for hwmon
patches as the subsystem is pretty much self-contained (the things I am
working on at least) plus I do built-test and to some extent run-test
the patches continuously, so I am confident my approach isn't breaking
bisectability.

But I have heard you nevertheless and already slightly changed my
process. I will no longer be "rebasing" during the merge window, i.e.
the first pull request I send during the merge window, which contains
the patches that have been waiting or have been added since the
previous merge window, will now be based on the just-released .0
kernel, rather than the current pre-rc1 state of Linus' tree at the
time I issue the pull request. Hopefully this should address your "test
results are lost" concern.

I don't think there's much more I can offer. I have to work with a
relatively recent tree so I have to "rebase" from times to times
anyway. At least once per development cycle, right? And I don't think
it would be very reasonable to stay on -rc1 all the time. That's why I
follow upstream development between -rc1 and final, and will only stop
doing so between final and -rc1. Staying with .0 wouldn't be reasonable
either, there's a reason why we maintain stable kernels trees. I don't
think you want developers to base their work on the previous stable
kernel, right?

You see, I don't want to make your life harder or anything. It's just
that your request doesn't make sense to me. "Don't rebase" is not
something I can do much with, as I do have to follow upstream
development and rebase at some point in time anyway. If you propose a
complete workflow which is better than what I do today, I'll be happy
to consider switching to it. But just telling me to skip one mandatory
step in my current workflow is simply not helping, sorry.

-- 
Jean Delvare
--
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/

Powered by blists - more mailing lists