Updates to Documentation criteria missing rationale and implementation details #159
Conversation
SecurityCRob
commented
Jan 24, 2025
SecurityCRob
commented
…n details <title> Signed-off-by: CRob <[email protected]>
| longer be actively supporting the project and | ||
| considering it "end of life") are important |
There was a problem hiding this comment.
Do we mean the project or versions of a project?
I expect that most projects, like most people, don't expect the end until it happens.
There was a problem hiding this comment.
hrm.... yes.... both versions and/or project closes up.
There was a problem hiding this comment.
Thinking about it... I wouldn't expect (for example) https://github.com/angular/angular to have a "we'll stop supporting the project on $DATE" until the project was already effectively dead.
I would expect them to have a "we'll stop supporting 6.x on $DATE", but that's a more nuanced statement.
There was a problem hiding this comment.
I don't want to be prescriptive on what support of comms channels projects must use. With implementation we can enhance the example to help projects understand better what the objective is and how their particular flavour may meet that requirement. As we get these criteria shored up, we should identify those things that lend themselves to being made into a template, so that folks could easily copy and edit them to meet their needs.
| Alternatively, the project could published their | ||
| desired support and duration through such outlets | ||
| as a project blog, mailing list, or FAQ. |
There was a problem hiding this comment.
I think the challenge here (and part of why this should be level 2 or level 3) is that there is no standard place to find this information for a project. For example, Istio data is fetched from https://istio.io/latest/docs/releases/supported-releases/, parsed through the selector: table argument and then run through a few regexes ('^~?(?P<value>\w+ \d+(, \d+)?).*', for example).
I'd love to see some better standards here, but I'm nervous about making this a requirement without a clear way to measure compliance or for consumers to use the result. If we want to push security-insights, we could try to enforce that as a mechanism, though I think current adoption is fairly low.
There was a problem hiding this comment.
As much as I desire one location to store this, it has never naturally developed over the last decade(s). As we roll this out as a standard for LF projects, we could be more prescriptive with how this should be implemented (and automated/templatetize it for our projects) then as others saw it, they could possibly adopt that location.
There was a problem hiding this comment.
Yes, that's what I'm advocating for. I think it's okay to take one or two items and say "hey, here's a standard place to put this" and people will either create the file or symlink it if the requirements are fairly easy to fit with their existing content. In turn, that will make the work of folks like endoflife.date easier.
I suspect it's part of a more-mature project, so at least level 2 (my other PR, no need to include it here).
There was a problem hiding this comment.
One thing that occurred in discussion this week in Minder was that projects using GitHub releases could actually update existing releases to include some release text indicating when a release is out of support.
I'm not sure what similar options are available for container images, helm charts, and language packages.
adjusted text to attempt to meet Evan's ask Signed-off-by: CRob <[email protected]>
