James Bottomley wrote:
So does this indicate the meaning of upstream and upstream-fixes is
still the same? I always took upstream-fixes to be bug fixes for this
-rc and upstream as queued for the next merge window, in which case NEXT
would be the union of those two sets?
In practice, #upstream-fixes isn't very useful, because I send its
contents to Linus very very rapidly once they are committed to that
branch. I then locally delete that branch once Linus merges it, and
re-create it [again, locally] the next time I have some bug fixes to apply.
So it is a "somewhat throwaway" branch.
The main utility of #upstream-fixes is so that I can do
git branch upstream-linus upstream-fixes
and then continue making commits in parallel with a Linus pull+push cycle.
The #upstream branch is much more useful, because that is where things
for the next kernel are stored, during a bug-fix-only cycle. This is
largely equivalent to NEXT, though I plan to be more stringent in my
requirements for NEXT commits than #upstream commits.
One thing to note is that "pure" rebases are somewhat rare; I much
prefer to wait until the batch of commits lands in
torvalds/linux-2.6.git, before I blow away and recreate (with a new
torvalds HEAD) the branch in question.
So, to answer your question... Fixes should go upstream fast enough
that they should hit NEXT implicitly via a Linus pull+push. It should
be the union of two sets, yes, if a Linus cycle takes a long time. When
both #upstream and #upstream-fixes are active, I tend to always branch
#upstream off of #upstream-fixes and/or do a "git pull . upstream-fixes"
when updating #upstream.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
