On Wed, Oct 23, 2013 at 07:30:33PM +0200, Richard Cochran wrote: > On Tue, Oct 22, 2013 at 11:24:11AM +0200, Thierry Reding wrote: > > > > Oh, I've been doing that for quite a while. In fact the patches that > > gave rise to the current frustration have been in a separate tree in > > various forms for over a year. But that's not what we want, is it? > > I can't see anything wrong with that. Your code is not the first to > have to wait for a long time before being finally merged. Think of > alsa, or of the pps stuff, or wakelocks, or preempt_rt, etc, etc. Heh... that's no news for me. > As an end user, I don't mind waiting for a feature if that means > stability and QA. If I get impatient, still I always have the choice > to take a development version. But I do not want to be forced to take > unfinished work in a released kernel. This isn't about stability and QA. The DT binding has nothing to do whatsoever with the quality of the code. Also in many cases with DT we end up with work that's actually finished and pretty well tested, and the only thing blocking it is the DT binding. > > I > > used to think that we actively wanted people to contribute code back > > upstream, so telling everyone to keep code in their own trees isn't > > helping anyone. > > Actually, I mean to propose that the ARM/DT people use a single > marshaling tree, one step away in the process from mainline. I don't think fragmentation of that sort will do us any good. It will only make it harder to get things merged because they get developed outside of the upstream process. Thierry
Attachment:
pgpMA6v7lvr2a.pgp
Description: PGP signature
