[RFC] [PATCH] Provide users with project support status

[RFC] [PATCH] Provide users with project support status

[Ruslan Bilovol]

When OE/Yocto project goes through its lifecycle, there
is no any way to identify where it is other than go
to a Yocto wiki and look at current status.

Moreover, change from maintained to community maintained
end EOLing happens silently so users not always know
about that.

This patch aims to remove this gap. The status should
be changed so users can clearly identify at which point
it is now:
 Development -> Stable -> Community supported -> End Of Life

It is now printed during the build.

It will be also captured in the git history and
may be discussed over mailing lists during such a patch
reviews.

In the future this can be extended also to LTS when
we will have it

Signed-off-by: Ruslan Bilovol <ruslan.bilovol@gmail.com>
---
 meta/conf/bitbake.conf       | 5 ++++-
 meta/conf/documentation.conf | 1 +
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 263d8aea4f..795dd3d5fb 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -6,6 +6,9 @@
 # files may also need changes to keep in sync.
 #
 
+# Project support level
+SUPPORT_LEVEL = "Development"
+
 # Used by multilib code to change the library paths
 baselib = "${BASELIB}"
 baselib[vardepvalue] = "${baselib}"
@@ -701,7 +704,7 @@ PREFERRED_PROVIDER_virtual/fakeroot-native ?= "pseudo-native"
 
 # Pre-build configuration output
 BUILDCFG_HEADER = "Build Configuration:"
-BUILDCFG_VARS = "BB_VERSION BUILD_SYS NATIVELSBSTRING TARGET_SYS MACHINE DISTRO DISTRO_VERSION TUNE_FEATURES TARGET_FPU"
+BUILDCFG_VARS = "SUPPORT_LEVEL BB_VERSION BUILD_SYS NATIVELSBSTRING TARGET_SYS MACHINE DISTRO DISTRO_VERSION TUNE_FEATURES TARGET_FPU"
 BUILDCFG_VARS[type] = "list"
 BUILDCFG_NEEDEDVARS = "TARGET_ARCH TARGET_OS"
 BUILDCFG_NEEDEDVARS[type] = "list"
diff --git a/meta/conf/documentation.conf b/meta/conf/documentation.conf
index 550df20b0f..3efef4b18b 100644
--- a/meta/conf/documentation.conf
+++ b/meta/conf/documentation.conf
@@ -392,6 +392,7 @@ STAGING_KERNEL_DIR[doc] = "The directory with kernel headers that are required t
 STAMP[doc] = "Specifies the base path used to create recipe stamp files. The path to an actual stamp file is constructed by evaluating this string and then appending additional information."
 STAMPS_DIR[doc] = "Specifies the base directory in which the OpenEmbedded build system places stamps."
 SUMMARY[doc] = "The short (80 characters or less) summary of the binary package for packaging systems such as opkg, rpm or dpkg. By default, SUMMARY is used to define the DESCRIPTION variable if DESCRIPTION is not set in the recipe."
+SUPPORT_LEVEL[doc] = "Specifies the project support level which can be one of 'Development', 'Stable', 'Community supported' or 'End Of Life'."
 SVNDIR[doc] = "The directory where Subversion checkouts will be stored."
 SYSLINUX_DEFAULT_CONSOLE[doc] = "Specifies the kernel boot default console."
 SYSLINUX_OPTS[doc] = "Lists additional options to add to the syslinux file."
-- 
2.17.1

✗ patchtest: failure for Provide users with project support status

[Patchwork]

== Series Details ==

Series: Provide users with project support status
Revision: 1
URL   : https://patchwork.openembedded.org/series/20873/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Patch            [RFC] Provide users with project support status
 Issue             Shortlog does not follow expected format [test_shortlog_format] 
  Suggested fix    Commit shortlog (first line of commit message) should follow the format "<target>: <summary>"



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines:     https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite:     http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

Re: [RFC] [PATCH] Provide users with project support status

[Adrian Bunk]

On Fri, Nov 01, 2019 at 07:46:38PM +0100, Ruslan Bilovol wrote:
> When OE/Yocto project goes through its lifecycle, there
> is no any way to identify where it is other than go
> to a Yocto wiki and look at current status.

The status in the wiki can be updated.

> Moreover, change from maintained to community maintained
> end EOLing happens silently so users not always know
> about that.
> 
> This patch aims to remove this gap. The status should
> be changed so users can clearly identify at which point
> it is now:
>  Development -> Stable -> Community supported -> End Of Life
> 
> It is now printed during the build.
>...

What is printed is the status at the point in the
(sometime distant) past when a release was made.

It is not uncommon for hardware to come with an example BSP based
on an older release like for example Yocto 2.0.3 (sic) today.

The Yocto 2.0.3 release shipped as part of this distribution would
never print "End Of Life".

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [RFC] [PATCH] Provide users with project support status

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1856 bytes --]

I too think that the information may never reach the target audience, as
they could never update their builds to the point where it would start
printing 'end of life'.

What could work instead is printing a link to the wiki during
'oe-init-build-env'.

Alex

On Fri, 1 Nov 2019 at 21:12, Adrian Bunk <bunk@stusta.de> wrote:

> On Fri, Nov 01, 2019 at 07:46:38PM +0100, Ruslan Bilovol wrote:
> > When OE/Yocto project goes through its lifecycle, there
> > is no any way to identify where it is other than go
> > to a Yocto wiki and look at current status.
>
> The status in the wiki can be updated.
>
> > Moreover, change from maintained to community maintained
> > end EOLing happens silently so users not always know
> > about that.
> >
> > This patch aims to remove this gap. The status should
> > be changed so users can clearly identify at which point
> > it is now:
> >  Development -> Stable -> Community supported -> End Of Life
> >
> > It is now printed during the build.
> >...
>
> What is printed is the status at the point in the
> (sometime distant) past when a release was made.
>
> It is not uncommon for hardware to come with an example BSP based
> on an older release like for example Yocto 2.0.3 (sic) today.
>
> The Yocto 2.0.3 release shipped as part of this distribution would
> never print "End Of Life".
>
> cu
> Adrian
>
> --
>
>        "Is there not promise of rain?" Ling Tan asked suddenly out
>         of the darkness. There had been need of rain for many days.
>        "Only a promise," Lao Er said.
>                                        Pearl S. Buck - Dragon Seed
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 2598 bytes --]

Re: [RFC] [PATCH] Provide users with project support status

[Andrey Zhizhikin]

On Sat, Nov 2, 2019 at 12:02 PM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:
>
> I too think that the information may never reach the target audience, as they could never update their builds to the point where it would start printing 'end of life'.

Would it make sense to include this message in base-files recipe?
Yocto does similar things with distro and machine name in /etc/issue
on target rootfs via do_install_basefilesissue(), so including this
state tag here would be also beneficial. Besides, users would see it
on every boot.

>
> What could work instead is printing a link to the wiki during 'oe-init-build-env'.

IMHO: This I think is beneficial for developers, but rather obscure to
the general audience which is booting device....

>
> Alex
>
> On Fri, 1 Nov 2019 at 21:12, Adrian Bunk <bunk@stusta.de> wrote:
>>
>> On Fri, Nov 01, 2019 at 07:46:38PM +0100, Ruslan Bilovol wrote:
>> > When OE/Yocto project goes through its lifecycle, there
>> > is no any way to identify where it is other than go
>> > to a Yocto wiki and look at current status.
>>
>> The status in the wiki can be updated.
>>
>> > Moreover, change from maintained to community maintained
>> > end EOLing happens silently so users not always know
>> > about that.
>> >
>> > This patch aims to remove this gap. The status should
>> > be changed so users can clearly identify at which point
>> > it is now:
>> >  Development -> Stable -> Community supported -> End Of Life
>> >
>> > It is now printed during the build.
>> >...
>>
>> What is printed is the status at the point in the
>> (sometime distant) past when a release was made.
>>
>> It is not uncommon for hardware to come with an example BSP based
>> on an older release like for example Yocto 2.0.3 (sic) today.
>>
>> The Yocto 2.0.3 release shipped as part of this distribution would
>> never print "End Of Life".
>>
>> cu
>> Adrian
>>
>> --
>>
>>        "Is there not promise of rain?" Ling Tan asked suddenly out
>>         of the darkness. There had been need of rain for many days.
>>        "Only a promise," Lao Er said.
>>                                        Pearl S. Buck - Dragon Seed
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Regards,
Andrey.

Re: [RFC] [PATCH] Provide users with project support status

[Adrian Bunk]

On Sat, Nov 02, 2019 at 12:01:38PM +0100, Alexander Kanavin wrote:
> I too think that the information may never reach the target audience, as
> they could never update their builds to the point where it would start
> printing 'end of life'.
> 
> What could work instead is printing a link to the wiki during
> 'oe-init-build-env'.

What should the user do based on this link?

Currently the wiki does not even state EOL dates for supported releases,
and it is not made clear that "Community" is just an euphemism for EOL.

Many products are just using the example BSP provided with the reference 
hardware.

With Ubuntu most 3rd party development happens to their LTS releases,
and when the example BSP for the reference hardware is based on Ubuntu
it is usually based on an LTS release.

Many Yocto questions are coming from people who seem to be just starting
a new project based on an already no longer upstream supported Yocto
release.

The easiest way to get long-term security support in such a situation
is often to take the required parts from the BSP layer, and use them
to build the product on top of Ubuntu LTS (or Debian).

The core question should really be how to increase the time of upstream 
support that is usually left when a Yocto-based distibution reaches the 
user, not just how to tell users that they are screwed.

> Alex

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [RFC] [PATCH] Provide users with project support status

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

On Sat, 2 Nov 2019 at 16:30, Adrian Bunk <bunk@stusta.de> wrote:

> The easiest way to get long-term security support in such a situation
> is often to take the required parts from the BSP layer, and use them
> to build the product on top of Ubuntu LTS (or Debian).
>

There is an alternative: engineer the product in such a way that it can be
updated from one Yocto release to a newer Yocto release.
This is what I will be pushing for where I work (Daimler).


> The core question should really be how to increase the time of upstream
> support that is usually left when a Yocto-based distibution reaches the
> user, not just how to tell users that they are screwed.
>

I'd say information about YP support windows should be more widely known,
both because it is useful in itself, and because maybe the users will talk
with their company management and with the project, and figure out ways to
improve the situation.

Alex

[-- Attachment #2: Type: text/html, Size: 1432 bytes --]

Re: [RFC] [PATCH] Provide users with project support status

[Adrian Bunk]

On Sat, Nov 02, 2019 at 04:54:37PM +0100, Alexander Kanavin wrote:
> On Sat, 2 Nov 2019 at 16:30, Adrian Bunk <bunk@stusta.de> wrote:
> 
> > The easiest way to get long-term security support in such a situation
> > is often to take the required parts from the BSP layer, and use them
> > to build the product on top of Ubuntu LTS (or Debian).
> 
> There is an alternative: engineer the product in such a way that it can be
> updated from one Yocto release to a newer Yocto release.
> This is what I will be pushing for where I work (Daimler).

This is surely desirable but it can only reduce the pain when upgrading,
not make upgrading painless.

Don't let anyone use the gpsd client libraries directly or use the gpsd
functionality to send data over the network - these often bring breaking
changes in new Yocto versions.

"async" becoming a keyword in Python 3.7 broke plenty existing code and
similar breakages might happen in the future, so Python cannot be made
available in such a product.

Do not use glibc in your product, it can happen that some obscure 
cornercase was made more standards-compliant - and one of your
users was relying on exactly the old behaviour.

These are just some of the real-life examples I have seen in the
past 12 months, and these are only cases of intentional upstream
changes - there is also some amount of regressions that are just bugs.

> > The core question should really be how to increase the time of upstream
> > support that is usually left when a Yocto-based distibution reaches the
> > user, not just how to tell users that they are screwed.
> 
> I'd say information about YP support windows should be more widely known,
> both because it is useful in itself, and because maybe the users will talk
> with their company management and with the project, and figure out 
> ways to improve the situation.

What is actually the minimum investment for that?

Six digit sums are small change for companies like Daimler,
but that's a huge amount of money for all the small companies
with a two digit number of employees making embedded products
that just happen to use Yocto.

Yocto lacks a setup where small companies could contribute with
four digit amounts to shared efforts like 5 years of LTS support.

Otherwise the only improvement available is often "don't use Yocto".

> Alex

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed