On Mon, 2020-02-03 at 19:23 +0200, Adrian Bunk wrote: > On Mon, Feb 03, 2020 at 07:58:54AM -0800, akuster808 wrote: > > On 2/3/20 1:38 AM, Adrian Bunk wrote: > > > On Sun, Feb 02, 2020 at 11:48:49PM +0000, Richard Purdie wrote: > > > > On Mon, 2020-02-03 at 01:13 +0200, Adrian Bunk wrote: > > > > ... > > > > > 2. Branch change when changing to community maintainance > > > > > would be bad > > > > > > > > > > This would silently break any automated setup that follows a > > > > > stable > > > > > branch for getting security updates. > > > > This I disagree with, quite strongly. > > > > > > > > When something moves to community support, it means the testing > > > > and > > > > quality could change. > > > Regarding testing, the only documented difference between LTS > > > branches > > > and community branches is "Automated testing is on a best effort > > > basis". > > > > That is the same difference of Stable branches and Community > > supported. > > What is not noted is the Build configurations along with Automated > > Testing it the unknown for Community support. > > > Regarding other quality aspects, I do not see why the community > > > branch > > > patch review and merging process has to be different from the > > > normal > > > stable process. > > Stable has to pass builds on the AB and the tests included. Dot > > releases > > include a formal QA run. > > > > Community is unknown. > > For community support branches the maintainer is required to publish > a test plan. > > Easiest for everyone would be if stable/LTS/community branches all > use the same processes for patches.
The trouble is I very much doubt anyone is going to setup a copy of the autobuilder to test community supported releases. This implies the community branches have to use the autobuilder to run the tests. At that point if we're using all the project resources, we may as well give up on the community level of support and extend the stable release. I'd love to say we can use the autobuilder everywhere for everything but its a finite resource and there are challenges to doing that which we may or may not be able to address... Cheers, Richard _______________________________________________ Openembedded-architecture mailing list Openembedded-architecture@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
