On 10/17/19 3:11 PM, Theodore Y. Ts'o wrote:
On Thu, Oct 17, 2019 at 02:23:58PM +0200, Vegard Nossum wrote:
Of course, this relies strongly on actually having (correct) sha1
references to previous versions inside the changelog. In my original
idea, this reference would only appear inside the merge commit that
binds the patchset together to minimise churn, although maybe it is
feasible to also append it to each patch -- in that case, the "patchset"
command from my first email is not sufficient to create a new version of
a patchset.
This also relies on the base of the commit actually being a public
SHA1. Sometimes developers will cherry-pick in a patch that they need
so that the kernel will actually *boot* (or otherwise fix problems
that have been fixed in other subsystems, but not yet landed in -rc2
or -rc3).
Of course, we could tell people that they should always create their
patches off of the last stable version (but then there may have been
changes pulled in via the last merge window that makes their patch not
apply), or they could be told to develop against -rc2 or -rc3, and
then cherry pick the required fix-up patches on top of -rc2 and -rc3,
but then they have to do a lot more rebuilding.
So there are no perfect solutions here, and while in the ideal world,
-rc2 and -rc3 should be perfectly stable enough for developers so that
they never need to manually patch in stablization patches, we need to
live in the real world. I believe that Darrick told me that in the
previous development cycle, he had to wait until -rc4 before the tree
was stable enough for him to start building xfs patches on top
mainline.
(This is also true for this development cycle if you enable
CONFIG_KMEMLEAK, although fortunately, the workaround that worked for
me was to just CONFIG_KMEMLEAK --- although of course, if I do have to
run a KMEMLEAK test run, I'll need to cherry-pick the fix which landed
this week on top of the ext4 git tree.)
What this all might mean is that sometimes it will make sense to allow
the user to override the base commit so such stablization patches can
be elided. Of course, we could force the user to create a separate
branch and rebase, but can be quite painful and slow --- and they
won't be able to test the rebased branch anyway, unless we then want
to tell them to cherry pick the stablization patches on top, and then
remove them before running "git send-email".
Good points.
I suspect that you should almost always be able to find a good base
revision to build and test your changes on.
In your example, couldn't Darrick simply base his xfs work on the latest
xfs branch that was pulled by Linus? That should be up to date with all
things xfs without having any of the things that made Linus's tree not
work for him.
Otherwise, you could apply the stabilisation patches and then do your
final testing in a branch that merges that with your patchset, like so:
rc1 o -----> fixup A ------> fixup B ---->o merge (tested)
(base) \ /
\ /
---> patch 001 --> patch 002 -->o patchset (submitted)
It does not seem too hard to me, and it should be pretty safe from a
test-what-you-ship point of view assuming the fixups and your patches
really are independent.
I think the more difficult problem to solve might be how to ensure that
the base commit is actually public/reachable when this is the intention.
A bot watching the mailing list could always respond with a "Hey, I
don't have that, could you rebase the series or push it somewhere?". But
it would be even better if git could tell you when you're about to
submit a patch. Maybe something like:
git send-email --ensure-reachable-from [remote] rev^^..
In the worst case, I guess the base commit will just not be available --
the email will still have a sha1 on it, though, and which might still be
usable as an identifier for the patch/patchset. If not, it's still not
worse than the current workflow (which would still work).
Vegard
