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.
And I have scripts to help turn the result into something suitable for
quilt, making the use of quilt a pain rather than a nightmare.

I do find quilt useful when backporting a series of patches so that I
can resolve the conflicts on each patch individually and move backwards
and forwards through the list of patches.  I don't think git has an easy
way to store a branch of patches-that-I-need-to-apply and to then give
me one at a time, removing them from the branch.  I could use 'stgit'
for that if necessary, though it is very tempting to write something
that is better integrated with git.

> during new releases they use quilt for all of their work, adding and
> removing and updating patches all the time.

So you are saying quilt is good for release management, and Guenter is
saying it is bad for development.  Maybe you are in agreement.

It probably is quite useful when pulling in a new -stable base.  We
typically have a bunch of patches that we applied before they came out
in -stable, and just removing them has some value ... though
occasionally I do wonder "what happened to that patch..... oh, stable!".

Personally, I would rather do all my kernel development (and non-kernel
development) using git and git only.  Other engineers might have
different opinions.  But we work with what we have.

NeilBrown

>
> There are the usual merge issues with doing that, but for an SoC, I
> don't think that would be all that hard given that almost all patches
> are driver/subsystem-specific and don't touch other places.
>
> It does take a better calibre of developer to do this type of thing,
> that might be a harder thing to deal with at some SoC vendors :)
>
> thanks,
>
> greg k-h
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss