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

[Darren Hart]

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).

>
>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 Hart					Open Source Technology Center
darren.hart at intel.com				            Intel Corporation