From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sascha Hauer Subject: Re: devicetree repository separation/migration Date: Sat, 22 Feb 2014 19:16:23 +0100 Message-ID: <20140222181623.GK17250@pengutronix.de> References: <20140217180544.GU7862@titan.lakedaemon.net> <20140218155750.GS17250@pengutronix.de> <20140218181854.GB7862@titan.lakedaemon.net> <20140220113832.D9E13C4050F@trevor.secretlab.ca> <0F360BC4-77AC-44E4-85FA-A8AAA336BA4D@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <0F360BC4-77AC-44E4-85FA-A8AAA336BA4D-uzTCJ5RojNnQT0dZR+AlfA@public.gmane.org> Sender: devicetree-compiler-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Warner Losh Cc: Grant Likely , Olof Johansson , Rob Herring , Tim Bird , Jason Cooper , Ian Campbell , Pawel Moll , Mark Rutland , Kumar Gala , Rob Landley , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: devicetree@vger.kernel.org On Fri, Feb 21, 2014 at 11:27:29AM -0700, Warner Losh wrote: > > On Feb 20, 2014, at 4:38 AM, Grant Likely wrote: > > > On Wed, 19 Feb 2014 13:20:15 -0800, Olof Johansson wrote: > >> On Wed, Feb 19, 2014 at 1:12 PM, Rob Herring 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. > > I wasn't in Edinburgh... Was this at the binary level or at the > source level? I'm thinking specifically about the move to cpp in the > back of my mind... Only the binary compatibility matters. The source can change without breaking compatibility between kernels and devicetrees. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -- To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html