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
<richard.purdie@...
<mailto:richard.purdie@...>> 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
