[OE-core] 3.0 release notes / migration guide
akuster808
akuster808 at gmail.com
Wed Oct 2 23:32:11 UTC 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 Openembedded-core
mailing list