User: Password:
Subscribe / Log in / New account

How to develop against linux-next

How to develop against linux-next

Posted Jul 9, 2008 17:44 UTC (Wed) by iabervon (subscriber, #722)
In reply to: How to develop against linux-next by jejb
Parent article: The current development kernel is...linux-next?

The problem isn't that developing against a rebasing tree is too difficult, because it's
generally not too hard to update things. The problem is that developing against a rebasing
tree generates a repository which isn't suitable for inclusion in the rebasing tree. That is,
following your instructions would be fine if -next weren't a useful tree to try to get your
stuff into, but the resulting repository isn't something that Stephen can pull into -next.

I suppose if you're targeting 2.6.n+3 (or later) for inclusion, you could develop against
-next, but that's sort of pessimistic. And I think that, if it makes sense to publish your
changes at all, it makes sense to have them in a state where they go against vanilla linus.

Also note that, if you develop against -next, either it doesn't matter, because you don't have
any interactions with other people's changes, or you're going to waste a lot of time when a
tree that you interact with gets some conflict and Stephen drops it (requiring you to resolve
a slew of conflicts) and then picks it up again the next day (requiring you to resolve the
same slew of conflicts the other way, back to essentially the state you had before). And that
applies to quilt as well; quilt will happily let the base change under it, but you'll have
days when your code won't work without a pile of fixups, and the "bug" it will be due to is
that some code that you now require is temporarily and intentionally missing.

(Log in to post comments)

How to develop against linux-next

Posted Jul 9, 2008 19:14 UTC (Wed) by jejb (subscriber, #6654) [Link]

Well, if you're running a development tree, it isn't eligible for inclusion into linux-next,
since linux-next only consists of everything that will go in in the next merge window.  What
you'd be developing this way is a patch series being posted to a mailing list and refined.
Once it's ready for inclusion, and everyone's signed off, then you get your own tree or send
them to a subsystem maintainer (and usually the latter if you have conflicts against linus
because you need to go through the tree of the subsystem you're in conflict with).

With this method of development, you can be targeting 2.6.n+1 since the delta between linus
and linux-next goes to zero within the merge window.

The whole point of developing against linux next is to see where you do pick up conflicts.  If
you do and you don't resolve them (which the rebasing method allows you to), Linus is hardly
going to choose to merge your tree over the subsystem tree you just conflicted with.  It's far
easier to resolve conflicts incrementally (as in daily) than wait for weeks and see how bad it
becomes (believe me, I've done both).

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds