lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 14 Feb 2008 16:45:49 -0500 From: Jeff Garzik <jeff@...zik.org> To: James Bottomley <James.Bottomley@...senPartnership.com> CC: Stephen Rothwell <sfr@...b.auug.org.au>, Andrew Morton <akpm@...ux-foundation.org>, linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>, Linux IDE mailing list <linux-ide@...r.kernel.org>, Linus Torvalds <torvalds@...ux-foundation.org> Subject: Re: linux-next: first tree 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-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