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, 21 Sep 2006 15:44:15 -0700 (PDT) From: David Miller <davem@...emloft.net> To: davej@...hat.com Cc: jeff@...zik.org, davidsen@....com, torvalds@...l.org, alan@...rguk.ukuu.org.uk, linux-kernel@...r.kernel.org Subject: Re: 2.6.19 -mm merge plans From: Dave Jones <davej@...hat.com> Date: Thu, 21 Sep 2006 18:05:39 -0400 > On Thu, Sep 21, 2006 at 02:52:08PM -0700, David Miller wrote: > > > I think the even/odd idea is great, personally. And if this > > makes some people have to wait a little bit longer for their > > favorite feature to get merged, that's tough. :-) > > My concern is that people will 'sit out' the even stage, and > just accumulate stuff in a single tree they dump once when > every odd release opens up. At least they would be dumping on top of "mostly working". I kind of like that. It breeds more confidence into the tree having been working before the dump took place, thus making the isolation of cause much easier. > We already have some subsystems that do once-per-release merges, > and then let fixes build up in their out-of-tree SCM for months > until the next window. It won't necessarily get worse, but unless > everyone is participating in the odd/even rules, we won't get > the benefits that it would offer. Having odd/even rules kind of adds legitimacy to the per-tree folks doing the same. This avoids situations like "why is XXX being an asshole with his tree, when there are other trees merging new features this round?". Having buy-in from everyone is very useful and gets folks in the correct mindset. - 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