[yocto] [OE-core] 3.0 release notes / migration guide

akuster808 akuster808 at gmail.com
Wed Oct 2 16:32:11 PDT 2019



On 10/2/19 3:57 PM, Paul Eggleton wrote:
> On Thursday, 3 October 2019 11:44:53 AM NZDT akuster808 wrote:
>> On 10/2/19 3:20 PM, Paul Eggleton wrote:
>>> So it's that time again - we need to start building up the raw material for 
>>> the release notes and migration guide for the upcoming 3.0 release, and I'd 
>>> like to request some help with some parts of it - read on for details.
>>>
>>> For the migration guide we have a wiki page serving as a staging area:
>>>
>>>   https://wiki.yoctoproject.org/wiki/FutureMigrationGuide
>> Thanks for putting this together.
> No problem!
>
>>> Things that should go in the migration guide: *anything* in the release that 
>>> would require someone who is upgrading to take some form of action (i.e. 
>>> change their configuration / recipes / etc.) Help with this from people who 
>>> implemented the changes or have already thought about / dealt with their 
>>> impact would be much appreciated.
>>>
>>> There is a process where I look through all the commits since the last release 
>>> and pull out the ones that need to be mentioned in some form - other than the 
>>> migration guide items, the following needs to be gathered for the release 
>>> notes:
>>>
>>> 1) Features - new functionality. We need to capture what the feature is and 
>>> hopefully express the impact to the user succinctly.
>> We remove LSB support.
> Thanks - I've just added that to the migration guide and will note it in the release notes.
>
>>> 2) Recipe upgrades - straightforward
>>>
>>> 3) CVE fixes - fairly straightforward, I just look for commits that explicitly 
>>> mention "CVE". If I can easily do so I'll also note where a recipe upgrade 
>>> fixes a CVE, but that isn't often readily available information.
>> So how can the community help in this case? Better commit messages?
> That would be great - but it does require the person doing the upgrade to look
> upstream, and of course every upstream is different. Unfortunately with some
> upstreams finding fixed CVE information is quite difficult indeed.
>
>> Well, aren't open defects not fixed by the time we release time but we
>> intend on fixing after release a form of known issues ?
> Yes, that's true - I will say we haven't been particularly systematic about the
> known issues in past releases so perhaps we should drive the list from
> bugzilla. I would want the list to be kept as short as possible though and each
> item should succinctly describe the issue. 

Maybe something the Yocto Bug triage team could possible assist in.   I
will bring it up tomorrow morning.

- armin

> Cheers
> Paul
>



More information about the yocto mailing list