From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Cooper Subject: Re: devicetree repository separation/migration Date: Wed, 19 Feb 2014 13:46:26 -0500 Message-ID: <20140219184626.GP7862@titan.lakedaemon.net> References: <20140217180544.GU7862@titan.lakedaemon.net> <20140218155750.GS17250@pengutronix.de> <20140218181854.GB7862@titan.lakedaemon.net> <5303DB5B.2090505@gmail.com> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lakedaemon.net; s=mail; t=1392835587; bh=hy29dp/BP2roQEHpWUftSRffQsKXA/CCt7OHNoeAJAw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=j8n7V715fjSTLlszyD5KVChqBRNcMrDN1bnaxq4bcwRaaNKEzY1vVOcN1MYspx6w9 7p0rwvZL0tXrtPJZL9k48gb8JZ5V3M7WXsKUfiDSve3GYKvnLw7Sb4XCAw2JEsB/lh ruaz6v3pzeJu7O4irr3JHVytYanMIPam4yeaSdBlomNaPy0R+ow9hsvKFlH3/mVmD0 7rzF2racPX2Ez3rdZSGLvRkw3CHkZ2SH7V2AiuI8yNCQk1EyG8QW6YhdBNLVNlqp4S oQXP9AUbtHEgYV2Aw6xluBwghIRU+YGNdvOs6C+3xWXFeOiMxJg0hP/mBSep5ZD9KV LM1ZomVTfVXag== Content-Disposition: inline In-Reply-To: <5303DB5B.2090505-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Sender: devicetree-compiler-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Frank Rowand Cc: Sascha Hauer , Grant Likely , Rob Herring , Ian Campbell , pawel.moll-5wv7dgnIgG8@public.gmane.org, mark.rutland-5wv7dgnIgG8@public.gmane.org, galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On Tue, Feb 18, 2014 at 02:14:51PM -0800, Frank Rowand wrote: > On 2/18/2014 10:18 AM, Jason Cooper wrote: > > On Tue, Feb 18, 2014 at 04:57:50PM +0100, Sascha Hauer wrote: > >> On Mon, Feb 17, 2014 at 01:05:44PM -0500, Jason Cooper wrote: > > ... > >>> - Is the Linux development workflow ready for devicetree to move out > >>> of the Linux Kernel? > >> > >> I hope so since keeping the devicetrees in sync with the kernel is a > >> pain for all external users. > > > > Well, I haven't heard any screams yet. I suspect people are waiting for > > details on the exact form it would take before complaining... > > < snip > > > Let me join the chorus of screams. > > I would venture that the number of linux kernel developers actively > touching device tree source files (and impacted by changes to them) > is vastly larger than any other set of developers. > > My experience in the kernel is already that finding working device > tree fragments that match current under development code is difficult. > (I am not trying to generalize for all systems, just the ones I use.) > > Moving the device tree source files out of the kernel git tree will > only make things worse. Having written/applied a significant portion of the arm devicetree files for several SoCs over the past couple of years, I share your concern. The reason I bring this up is because I keep seeing the little churn here and there because we _can_. I find it very similar to a teenager reaching adulthood. At a certain point, the parents have to say "Get out, get a job, get your own place." It's hard for all parties involved, but it's the best thing for the young adult in the long run. There's no substitute for living on your own and paying bills. I think the long term health of the devicetree would benefit greatly from being more detached than it currently is. It would force everyone to "Pay the bills". The time might not be right now, and it probably will take one of the more gradual forms Olof suggested. But I think it should happen at some point to help it grow up. And we still have the short term problem of facilitating other projects use of the devicetree. Which can only make it more robust and accepted by default. thx, Jason. -- 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