[linux-yocto] [PATCH 00/24] [linux-yocto-3.10] [Scenerio 1] Enable feature branch for Valley Island features

[Bruce Ashfield]

On 14-05-23 06:48 AM, Ong, Boon Leong wrote:
>>>>> So however you got a merge conflict. Your tree wasn't up to date.
>>>>>
>>>> I do not encounter any merge conflicts, is just that the branches is
>>>> not
>>> merging. By checking my build, I notice that the valleyisland-io-1.0
>>> branch has the same HEAD of standard/base (which means I don't see any
>>> I/O patches there in the feature branch that fetched by bitbake). This
>>> means that source tree I'm fetching during build time is not updated
>>> yet. Is there any occurrence that the new check-ins need some time to
>> reflect to end users?
>>>
>>> It could be a fetcher problem, since the branches are definitely not the
>> same.
>>>
>>> yow-bashfiel-d3 [/home/bruc....git-merge]> git describe standard/base
>>> v3.10.38-2595-g02f7e63e56c0
>>> yow-bashfiel-d3 [/home/bruc....git-merge]> git describe
>>> valleyisland-io-1.0
>>> v3.10.38-2618-g8ea4fb625f26
>
> Hi both,
>          I did some research onto the do_validate_branches logic and realize
> the reason why we are not seeing the correct commit that we want to have
> at valleyisland-io feature branch in the build folder.
>
> Basically, the logic below is force any branch not having the HEAD as the machine branch
> to be downgraded, i.e. valleyisland-io branch HEAD which is ahead of standard/base, is
> forced to be the same as the HEAD of standard/base after the following logic:
>
>   ==========================================================================
>
> **** target_branch_head is the standard/base SCRREV (set as HEAD) commit  *****
>
>          containing_branches=`git branch --contains $target_branch_head | sed 's/^..//'`
>          if [ -z "$containing_branches" ]; then
>                  echo "ERROR: SRCREV was set to \"$target_branch_head\", but no branches"
>                  echo "       contain this commit"
>                  exit 1
>          fi
>
> ****  after this logic, valleyisland-io will be listed under containing_branch because
>            the patchset is applied ontop of standard/base HEAD ******
>
>          # force the SRCREV in each branch that contains the specified
>          # SRCREV (if it isn't the current HEAD of that branch)
>          git checkout -q master
>          for b in $containing_branches; do
>                  branch_head=`git show-ref -s --heads ${b}`
>                  if [ "$branch_head" != "$target_branch_head" ]; then
>                          echo "[INFO] Setting branch $b to ${target_branch_head}"
>                          if [ "$b" = "master" ]; then
>                                  git reset --hard $target_branch_head > /dev/null
>                          else
>                                  git branch -D $b > /dev/null
>                                  git branch $b $target_branch_head > /dev/null
>                          fi
>                  fi
>          done
>
> **** The above logic force any branch listed in containing_branches (which valleyisland-io branch is in)
>           not having the same commit as KBRANCH to be downgraded to the be the same as
>           KBRANCH SRCREV commit  ****
> ==========================================================================
>
> The output of the do_validate_branch is as follow and confirmed the behavior.
>
> DEBUG: Executing shell function do_validate_branches
> [INFO] Setting branch standard/arm-versatile-926ejs to 02f7e63e56c061617957388c23bd5cf9b05c5388
> [INFO] Setting branch standard/axxia/base to 02f7e63e56c061617957388c23bd5cf9b05c5388
> [INFO] Setting branch standard/beagleboard to 02f7e63e56c061617957388c23bd5cf9b05c5388
> [INFO] Setting branch standard/ck to 02f7e63e56c061617957388c23bd5cf9b05c5388
> [INFO] Setting branch standard/edf to 02f7e63e56c061617957388c23bd5cf9b05c5388
> [INFO] Setting branch standard/fsl-mpc8315e-rdb to 02f7e63e56c061617957388c23bd5cf9b05c5388
> [INFO] Setting branch standard/mti-malta32 to 02f7e63e56c061617957388c23bd5cf9b05c5388
> [INFO] Setting branch standard/mti-malta64 to 02f7e63e56c061617957388c23bd5cf9b05c5388
> [INFO] Setting branch standard/ocf to 02f7e63e56c061617957388c23bd5cf9b05c5388
> [INFO] Setting branch standard/preempt-rt/base to 02f7e63e56c061617957388c23bd5cf9b05c5388
> [INFO] Setting branch standard/preempt-rt/fri2 to 02f7e63e56c061617957388c23bd5cf9b05c5388
> [INFO] Setting branch standard/preempt-rt/minnow to 02f7e63e56c061617957388c23bd5cf9b05c5388
> [INFO] Setting branch standard/preempt-rt/qemuppc to 02f7e63e56c061617957388c23bd5cf9b05c5388
> [INFO] Setting branch standard/preempt-rt/routerstationpro to 02f7e63e56c061617957388c23bd5cf9b05c5388
> [INFO] Setting branch standard/qemuppc to 02f7e63e56c061617957388c23bd5cf9b05c5388
> [INFO] Setting branch standard/routerstationpro to 02f7e63e56c061617957388c23bd5cf9b05c5388
> ****[INFO] Setting branch valleyisland-io-1.0 to 02f7e63e56c061617957388c23bd5cf9b05c5388****
> DEBUG: Shell function do_validate_branches finished
>
> Bruce, how do we resolve this? What is the practice in linux-yocto on feature branch?
> Do you know think that having all patches on standard/base is a more correct approach?

Ah .. crap.

It's bug that Darren and I ran into in the 1.6 release cycle, but the
changes to fix it were too big to get into 1.6. So this one is
unfortunately well known to us.

.. and I was testing with my new 12 patch series in my tree, so I don't
see the branch reset anymore (at least I know that the new code still
fixes the problem).

The fix at the moment is to make sure that the machine SRCREV is not
the head of standard/base, so the feature branches won't be reset.

I can contradict myself and pull the valleyisland-io branch back from
the top of standard/base, or push another change to standard/base, and
have you set that as your machine SRCREV.

Luckily, I have the .39 and .40 -stable updates already queued. I just
pushed them to your tree. Can you set your SRCREV to match this:

SRCREV_machine ?= "f53a6114b3a6e8c03ca4752de829887015f4c942"

And retry ?

Bruce



>
> We plan to release meta-valleyisland out together with other YP1.6 meta-intel release targeting
> next week.
> Appreciate your timely response here, so that we can adjust accordingly based on your merge strategy and
> eventually send in the last commit update for meta-valleyisland linux-yocto_3.10.bbapend.
>
> Many thanks!
>
>