On Wed, 19 Feb 2014 13:20:15 -0800, Olof Johansson <olof@xxxxxxxxx> wrote: > On Wed, Feb 19, 2014 at 1:12 PM, Rob Herring <robherring2@xxxxxxxxx> wrote: > > One way to minimize the inconvenience is keep versioning and dev > > cycles in sync with the kernel. We could also start doing things to > > align the kernel workflow with how things will work when we do have a > > separate repository. > > I don't think aligning development cycles is what we want most here it > might be useful for us in Linux but it'll make things difficult for > other projects since they're not aware of our release cycles. The > device tree bindings and DT contents in that repo should be "always > stable", i.e. no merge window / rc concept. As soon as something goes > in it's live, and from then out only fixes to the DTS files (or > appending the binding). > > For example, I don't want to have to track two trees to test against > -- I'll want to keep one repo of the very latest DT files and always > use those to boot any and all boards. This approach does have the subtle side effect that differs from what we discussed in Edinburgh. We've talked about always being able to boot a new kernel on an old devicetree, but not a new devicetree on an old kernel. With a separate board database repo we are going to hit both cases. At least to a limited extent we're going to need older kernels booting with the latest devicetree, and we'll need some rules about how that gets applied. The alternative is that binding changes land in .dts files after a kernel release, and I don't think we want that situation at all. This is an issue for new bindings, only when a binding is getting extended or replaced. If the change is merely adding new properties then there shouldn't be a problem (the old kernel will ignore the new properties). If it removes properties or creates a new compatible string (dropping the one supported by an older kernel) then it won't boot. Ultimately this is probably the right thing to do, but it will be difficult. Keeping a staging process for new bindings in lock step with the kernel is probably the way to mitigate this. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
