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.
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?
