[OE-core] Fwd: [oe-commits] [openembedded-core] branch thud updated (ad0a553 -> 748f946)

akuster808 akuster808 at gmail.com
Sat Mar 16 15:50:13 UTC 2019



On 3/16/19 5:20 AM, Andreas Müller wrote:
> On Sat, Mar 16, 2019 at 12:11 PM akuster808 <akuster808 at gmail.com> wrote:
>> On 3/15/19 10:24 AM, Andreas Müller wrote:
>>> Replied to wrong mailing
>>>
>>> On Wed, Feb 6, 2019 at 5:38 PM <git at git.openembedded.org> wrote:
>>>> This is an automated email from the git hooks/post-receive script.
>>>>
>>>> rpurdie pushed a change to branch thud
>>>> in repository openembedded-core.
>>>>
>>>>     from ad0a553  build-appliance-image: Update to thud head revision
>>>>      add 0bbe3d5  kernel: use olddefconfig as the primary target for KERNEL_CONFIG_COMMAND
>>>>      add 933712e  linux-yocto/4.18: update to v4.18.22
>>>>      add 193eb75  icecc: readlink -f on the recipe-sysroot gcc/g++
>>>>      add 57673fe  icecc: Trivial simplification
>>>>      add d4ec470  icecc: Syntax error meant that we weren't waiting for tarball generation
>>>>      add 46db052  icecc: Don't generate recipe-sysroot symlinks at recipe-parsing time
>>>>      add 9d3587d  icecc: patchelf is needed by icecc-create-env
>>>>      add d8bf7e5  eudev: upgrade 3.2.5 -> 3.2.7
>>>>      add a316146  gsettings-desktop-schemas: upgrade 3.28.0 -> 3.28.1
>>>>      add 88581ac  libatomic-ops: upgrade 7.6.6 -> 7.6.8
>>>>      add 7c6e9f5  libpng: upgrade 1.6.35 -> 1.6.36
>>>>      add be1429b  common-licenses: update Libpng license text
>>>>      add 93c76fe  i2c-tools: upgrade 4.0 -> 4.1
>>>>      add b09f261  oeqa/utils/qemurunner: Print output when failed to login
>>>>      add 47731b4  grub2: Fix passing null to printf formats
>>>>      add e3ef28a  gnupg: Upgrade to 2.2.12 release
>>>>      add a44c7ba  tzdata/tzcode-native: update to 2018i
>>>>      add 4a7945c  lighttpd: update to 1.4.51
>>>>      add 4f14eac  boost: update to 1.69.0
>>> In my infinite naivety I just updated thud.
>>>
>>> * Many updates here - wasn't there some policy just to update in case
>>> of 'emergency'?
>> Nope the process does not say that. I will update recipes when they
>> bugfix updates.  I have been doing that for years. In fact, you should
>> be seeing something on the arch list to make the process standard.
>>> * How can you update boost on a stable branch - a first class citizen
>>> for build trouble?
>> Don't recall the thought process on a given backport especial when its 3
>> months back. Can't tell why I decided to update boost.
>>
>> - armin
>>
>>> Wonder which further fallout I'll get...
>>>
>>> Andreas
> Just for the record:
>
> 1. In [1] I read at policies:
>
> * No recipe upgrades unless:
>   * The old version is completely broken
>   * The new version contains a security patch or other critical bugfix
> that is too difficult to backport to the version already in the stable
> branch
For completeness:

As always, the stable branch maintainers' judgement is important when it
comes to deciding which fixes are or are not appropriate. If there is
doubt, feel free to consult with the overall project maintainer (Richard
Purdie <richard.purdie at linuxfoundation.org>).


> 2. This was applied on Feb 6th which is not 3 month back exactly.
then its worst than I thought, I can't remember what my thought process
was back to Feb 6th.
>
> [1] https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance#Point_release

I am glad you are bringing these things up, it helps me revisit my own
processes and help me improve.

We are planning on revising the maintenance guidelines soon so I hope to
get your input.


- armin
>
> Andreas




More information about the Openembedded-core mailing list