[re-adding debian-kernel to the cc list, with Mark's permission] On Wed, 2005-09-28 at 11:28 -0700, Allyn, Mark A wrote: > Dann: > > I am curious, what happens if I submit patches only to www.kernel.org > (the upstream) and wait?
If they're accepted, they'll probably end up in a Debian kernel automatically. I say probably, because there are somethings that kernel.org permits which we don't - specifically binary firmware that is not explicitly redistributable. See my DebConf5 paper for more details on that topic. > If Debian does 'pull down' from www.kernel.org, than why would I need > to submit patches separately to Debian? You wouldn't, and that's exactly the point! Getting things upstream means all distros downstream will eventually pick them up without any additional effort on your part. However, if (for example) you want us to backport a driver from 2.6.14 into 2.6.12 so that it makes it into Debian faster, you'll have to file a bug and request it. If the driver has gone upstream, you've provided a patch against our (older) source, and there's a reason that waiting for 2.6.14 isn't sufficient[1], then that shouldn't be a problem. > If I merely wait, without submitting patches to Debian, how long would > it take for a patch that has been approved by Linus and company at > www.kernel.org before I see it naturally percolate into sid and then > etch? Once again, it depends :) There are many things that could potentially cause a delay. For example, right now 2.6.13 hasn't gone into sid yet because it is dropping devfs support, which means we have to get an initrd-tools replacement in good shape before we can upload it. 2.6.12 took a while, because we completely redid the packaging during that release. If we're near release, we might hold off on new upstream releases while we whip our candidate kernel into shape, or maybe upload a package with a different name to sid. We've not done a release with the new packaging yet, so this will be the first time we've had to figure that out. However, the kernel team has been very good about starting work on new upstream releases within days of a new release - so if there's no external dependencies holding us off, this could be as quick as a week. The things that cause delays are all problems that need to be fixed - if you want something to happen sooner, there is often something you can about it - that's the great thing about an open community. [1] reasons might be that we've decided to put 2.6.12 into etch, so 2.6.14 would be too late, or maybe your patch is in Linus' tree, but he has not released a new version yet -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
