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

[Paul Eggleton]

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. 

Cheers
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre