On Sat, 2021-12-11 at 06:12 -0800, akuster808 wrote: > > On 12/10/21 2:47 AM, Alexander Kanavin wrote: > > On Thu, 9 Dec 2021 at 18:05, Richard Purdie > > <[email protected] > > <mailto:[email protected]>> wrote: > > > > > > I'm in favour of adding the new category and I agree some kind of > > dates in the > > [reason] space would be nice to have. > > > > For the purposes of a patch upstream, the last commit date is much > > more > > important than a release. I don't think this needs to be machine > > readable as a > > definition, it is better we have the appropriate info. Year is > > probably as much > > as we need since inactive software is usually measured in years. > > > > > > Some upstreams are so old that they pre-date the 'git era' and > > tarballs are all there is. I guess either last commit or last release > > is ok, or both where possible. Dates can be full or can be shortened > > to YYYYMM or YYYY where needed. > > > > Something like: > > Upstream-Status: Inactive-Upstream [lastcommit: 2019, lastrelease: 2015] > > What about kernels? If the version this patch is against is EOL but a > similar form was accepted in a later version , how would that play out here?
Patch status tends to only really make the most sense on the development code branches and you couldn't say the kernel was inactive. Wouldn't the state be "Backport" in that case anyway? Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1387): https://lists.openembedded.org/g/openembedded-architecture/message/1387 Mute This Topic: https://lists.openembedded.org/mt/87612566/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
