On Fri, 2016-07-15 at 15:52 +1000, NeilBrown wrote:
> On Fri, Jul 15 2016, Greg KH wrote:
> > On Thu, Jul 14, 2016 at 07:56:43PM -0700, Guenter Roeck wrote:
> > > Overall, I can not imagine that it is even possible to use quilt
> > > trees as basis
> > > for development in a company with if active kernel development,
> > > even more so
> > > if a large number of engineers and/or a number of branches are
> > > involved.
> > > Sure, the QCOM example may be extreme, but do you really think
> > > that writing
> > > those 2.5M LOC would have been possible if QCOM had used Quilt
> > > trees instead
> > > of git ? Using Quilt would for sure have prevented them from
> > > writing those
> > > 2.5M LOC, but then there would be nothing. That doesn't sound
> > > like a feasible
> > > alternative either.
> > 
> > It is possible, look at the Red Hat and SuSE kernel development
> > teams.
> > Yes, in the end, most of the patches are backports from upstream,
> > but
> 
> You are glossing over a key point.  We (or at least I as a SUSE
> kernel
> developer) don't use quilt for development because, like Guenter
> says,
> it would be too clumsy.  I do development upstream if git.  Upstream
> first.

The same is true for Red Hat. We have had an "upstream first"
policy in place for over a decade now.

RHEL is just not where development happens, because development
happens upstream.

RHEL is also developed on a git tree nowadays, because there is
no need to extract patches from RHEL, since the code came from
upstream to begin with.

It sounds like the embedded people are causing themselves a lot
of pain. Pain the distro people got all too familiar with a decade
ago, and decided to leave behind.

-- 

All Rights Reversed.