You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The first is a fork of the second, and the second seems to be out-of-date; unfortunately the author did not mark it as archived. I also linked their deps.dev references. Unfortunately the securityscorecards.dev site doesn't provide a website view to check dependencies with.
@BenjamenMeyer, thank you, the examples are very interesting indeed. I believe these issues could be reported to scorecards project to investigate further and change its data retrieval pipelines.
These examples show that it is not always a reliable source of information. It can contain both false negatives and false positives. It might be a significant disadvantage for using deps.dev as a source of information. Therefore, we cannot make a decision to deprecate any packages based on this information forcefully.
On the other side, there are advantages too: the resource is already integrated into the project, and it is cheap to use it. What we could do with this is show the same checks in pkg.go.dev as is, and highlight when they are absent.
Is it a good enough solution to improve the visibility of unmaintained projects?
Another, more restrictive solution for this problem could be a mechanism to force the deprecation of packages. It might require direct access to the repository hosting APIs, but also changing the go.mod files of the packages to provide deprecation comments with a reason. Probably, it is possible, but I don't understand the corner cases and the full cost of such a solution, so it seems hard to develop and maintain.
@goto1134 if an author takes the step to mark their repo as unmaintained/archived then that should be an indicator to things like deps.dev, pkg.go.dev, etc to mark as deprecated. If the status gets removed then those sites should again reflect that - example: the Go Gorilla projects that were marked archived as the authors stopped and didn't have anyone to turn it over to; another team came in and resurrected it in place with the former teams permission and took over, unarchiving them in the process.
I would not use time since the last commit as that can be a misnomer. I have some projects myself that are maintained and active but haven't had changes in years, mostly because they still do what they were intended to do.
If we could get sites like deps.dev to integrate that data awesome. If not, I'd suggest we try to pull it ourselves where possible. Perhaps with an "unknown" or "unavailable" value for other cases where the vcs isn't accessible or not yet integrated.