On Sat, 2021-12-11 at 06:55 -0800, akuster808 wrote: > > On 12/11/21 6:15 AM, Richard Purdie wrote: > > 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? > Hard to say. It all depends on what came first. I have seen patches > against 5.4 for new SoC support that will never make in into the Stable > branch and made available before and a version is submitted in > upstream. The first one may be paying the bills. > > > Maybe I am looking at this too broadly. Do we want other layers to adopt > this patch status or is this just core and meta-openembedded?
The hope is something which can be broadly used but not every category has to perfectly match every corner case. >From the inactive perspective, I'd define it as "no upstream the changes could be submitted to". In the kernel case, it is clear that there is an usptream and people are just choosing not to for whatever reasons. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1389): https://lists.openembedded.org/g/openembedded-architecture/message/1389 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]] -=-=-=-=-=-=-=-=-=-=-=-
