[PATCH] [SRU] [b/master][b/snapdragon] separate linux-snapdragon into its own topic kernel

Kleber Souza kleber.souza at canonical.com
Fri Mar 29 11:21:22 UTC 2019

On 3/28/19 4:44 PM, Paolo Pisati wrote:
> On Thu, Mar 28, 2019 at 3:54 PM Kleber Souza <kleber.souza at canonical.com> wrote:
>>> 2) create a new bionic/linux-snapdragon branch and reset hard to my
>>> lp:snapdragon-topic-kernel branch  (see the pull request below)
>> Just to make sure I'm not missing something, does this mean the following
>> reference from the PR?
>> https://git.launchpad.net/~p-pisati/ubuntu/+source/linux 8f0d0ff453a88818b597fd3828157c7b9312e36f
> Yes
>>> 3) update bionic-meta to point to the new bionic/linux-snapdragon kernel
>> Do we have a patch for this change? I haven't found it in this thread.
> No, because meta is usually handled by stable

OK, we can handle that.

>>> While from the point of view of linux-snapdragon, with ~600 code commits and ~4k
>>> config changes, this represent a brand new kernel and while great care was used
>> Could these ~4k config change commits be squashed into a single commit named like
>> "initial snapdragon config"?
>> Having this amount of commits will make rebase take much longer than probably needed.
> I personally like to have the config bisectable, but if you prefer, i
> can squash all config commits and resend.

While it's good to have the config changes bisectable, it would make bisecting between
a previous commit and a later commit harder since the binary search would test a config
change most of the times.

With the current patchset from the PR, it's taking 10 min to do a rebase on my
local system. From the total ~5k patches, ~4k is config change so they probably
accounting for ~8 min of rebase time.

So I would say that having a single commit would be easier for us to maintain,
even if it breaks bisectability on the config changes.

Could you please send resend with those commits squashed?


More information about the kernel-team mailing list