[linux-yocto] [PATCH 00/24] [3.14] Baytrail driver updates

[Bruce Ashfield]

On 14-05-14 12:14 AM, Darren Hart wrote:
> On 5/13/14, 20:47, "Ong, Boon Leong" <boon.leong.ong at intel.com> wrote:
>
>>> Merged to standard/base (and then propagated out to all BSP branches).
>>> Keep an eye out for issues, but since this is mainline code, it is safe
>>> for all
>>> boards (i.e. not used), so nothing should go wrong :)
>>
>> Just want to clarify the practice below because it does conflicts with my
>> understand on linux-yocto only merges
>> commits from -stable branch.
>
> This isn't quite right. The general rule is that linux-yocto only accepts
> mainline backports to standard/base. Consider it more like LTSI than
> -stable. Features and new drivers are acceptable in linux-yocto
> standard/base so long as they are sufficiently self contained and do not
> put other BSPs at risk. Linux-yocto is, effectively, a "distro kernel" in
> terms of patch policy.
>
>> Is this true that with intel common kernel, standard/base is now
>> accepting patches of
>> type: (1) in-queue for mainline (2) yet to be in-queue for mainline.
>
> You're absolutely right that this is a stretch from the guiding principles.
>
> Of this series, there is only 1 patch that has any real risk of changing
> before merge - that's the PCI enumeration of the SPI bus. It has undergone
> quite a bit of review and we felt was likely baked enough to go in (I
> suspect it would also be acceptable to LTSI 3.14 - if such a thing
> existed). That was the criteria I used.
>
> All such patch series will have to be considered on a case by case basis
> and will be the exception, rather than the rule. We shouldn't plan for
> such things :-)
>
>>
>> Question to clarify on what is happening here on v3.14 standard/base:
>> 1) Will the patches in-flight for mainline be eventually cherry-picked
>> back to v3.14 -stable branch?
>
> No, because they are not all bug fixes. Some of them could be though and
> we should look into which if any have already been queued for stable, and
> then consider the rest.
>
>> The reason that I ask is, if someone does, I assume that these patches
>> which are now merged into standard/base
>> be dropped/updated with the commit back-ported into v3.14-stable branch?
>
> When Bruce does a "git merge v3.14.4" or whatever, the two trees will
> merge - that brings two different development branches together into one -
> you don't explicitly drop older versions of patches. If the merge becomes
> a problem, Bruce may choose to revert the problematic patches - but there
> is only one real candidate for that (the PCI SPI patch).

Exactly.

>
>>
>> 2) Why the patches not in-flight to mainline be lined-up on feature or
>> machine branch, then be merged into standard/base?
>
> There is only 1 really (the other two are trivial one liners which will be
> incorporated into future patches in mainline and disappear in the merges
> to follow). This one could have been in a feature branch. The reason it
> isn't is because after reviewing its history, I felt it was pretty much
> baked. Time will tell if that was the right call or not.
>
> It's possible we should have created a new standard/intel branch for all
> such things. In general though, that should only be necessary if we risk
> breaking other platforms with patches or if the patches are still under
> relatively active development. I would reject such patches anyway and
> suggest they go into a feature branch, so the standard/intel branch seemed
> unnecessary to me.
>
> Definitely an exception to the rule and you are right to ask for more
> detail on the decision making process here.

Darren hits on all the right points .. and I have very little to add, in
particular for BSPs.

I will point out that linux-yocto does contain features (like aufs,
crypto-dev, and others that come and go), which are also on the 
standard/base
branch to make them available to all BSPs.

For those features the same logic applies:

   - they must be safe for all boards
   - they must be sufficiently mature and functional

But due to the nature of getting changes into the mainline kernel, not
all of these features are candidates to merge there any time soon, but
go on standard/base regardless.

There are guidelines that we follow, but there are always per-feature
and per-patch decisions that are made .. and I'm always happy to
explain and discuss.

Good questions!

Bruce

>