On 14-05-14 12:14 AM, Darren Hart wrote:
On 5/13/14, 20:47, "Ong, Boon Leong" <[email protected]> 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
--
_______________________________________________
linux-yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/linux-yocto
