| 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, 19 Jun 2008 09:31:34 +1000 From: Benjamin Herrenschmidt <benh@...nel.crashing.org> To: James Bottomley <James.Bottomley@...senPartnership.com> Cc: ksummit-2008-discuss@...ts.linux-foundation.org, linux-kernel <linux-kernel@...r.kernel.org> Subject: Re: Request for discussion on when to merge drivers > The only slight wrinkle (at least for me) is that often the process of > cleaning up a driver is fairly intensive for a maintainer and turn > around is a lot faster if you're doing it in a tree you control. (All > the scsi drivers we've done like this have lived in temporary branches > while they were being worked on). So perhaps in addition we should be > encouraging maintainers to run staging branches under similar rules in > the staging tree, but allowing inclusion into linux-next? .../... linux-next should, imho, exclusively be for things we are pretty much commited to merge in the next release. ie, a staging place to fixup things like build breakages, patch conflicts, etc... Or else, it will just be another -mm .... So while what you say makes sense, I think we should only put drivers in once we have pretty much decided that the drivers in question would be merged... in which case, why not straight upstream ? Cheers, Ben. -- 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