Cc: Stephen Rothwell <sfr@...>, Andrew Morton <akpm@...>, <linux-next@...>, LKML <linux-kernel@...>, Linux IDE mailing list <linux-ide@...>, Linus Torvalds <torvalds@...>
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
--
