Clarify Archiving Process about toc

[benh]

Some suggestions for considering a project archivable:

• There haven't been any issues opened for N months (where N should be debated).
• Opened issues haven't received a response within M months (where M should be debated).
• It hasn't seen a commit in over O months (where O should be debated).
• It's binaries/source are no longer being downloaded (if it's even possible to track this).

IMO the TOC should be comfortable with a project that "just works" and is mostly "in maintenance" versus "actively developed". But if we want to make that clear to potential users then perhaps we have a 'Maintenance' status in addition to an 'Archived' status?

I also would prefer to see a project put into a 'Maintenance' state before it goes to 'Archived' so that maintainers have a chance to re-engage the community, and/or find new maintainers, if that's what the community wants before it jumps to 'Archived'.

[mattfarina]

Thanks for filing an issue on this @caniszczyk.

We have some projects with limited support. For example, Notary has had 13 commits in the past quarter in total. I'm not suggesting Notary or others should be archived. Just that they may be candidates to be evaluated for archival or an effort to reinvigorate engagement.

[caniszczyk]

@mattfarina

With Notary and any other project, it's hard to tell whether it's "mature and stable" or in a position that it should be archived. We generally take the stance that if a project wants to be archived, they can request it so to the TOC. CNCF is also committing to reviewing non-graduated projects on an annual basis to see if any warrant being archived.

[mattfarina]

@caniszczyk I chose Notary on purpose for several reasons:

1. It does not have a 1.0.0 release. If I look at something like SemVer it means there is no stable release. There is something to communicating expectations.
2. Other projects, such as the recently added Harbor, use Notary. It's a dependency for other CNCF projects so there are complicated implications.
3. The limited commits can raise the question of it moving to a 1.0 stable release.
4. Whether something needs to be re-invigorated or archived and how pursue both paths is worth talking about. Notary seems like a good case to flesh this out.

In my experience, when an open source project fills a need and has a good experience it's useful. But, that is often not enough to make it an ongoing success. Some things teetering on ongoing success have been overcome by other options and are OK to let go. Other things still fill a need and those projects needs to have sustainable life breathed into them. How does the CNCF do that?

[justincormack]

I don't think that Notary is in any way appropriate as an example; we are looking towards graduation not archiving. Yes it is fairly stable, but there are some parts of the TUF spec not implemented, which is the primary reason that it has not gone to 1.0 (although perhaps we could do a 1.0 release and then add those for 2.0). It is security code so the review process is more detailed than other projects, and the rate of contribution is lower for that reason. Just a few weeks ago Azure started production support of Notary, and IBM is in the process of contributing improved HSM support, and as you mention Harbor entered the CNCF as a project using Notary. Helm is also a potential user of a TUF based update model.

[caniszczyk]

@benh @mattfarina thanks for your comments, I put forth a proposal here based on some of your ideas: #170

RFC @cncf/toc

[rothgar]

How about projects that may not live up to UX, operational and development patterns, or are not adopted widely like we would expect for CNCF projects? I'm not sure what those standards are and they are very hard (possible impossible) to quantify but I think they should be considered.

I don't mean to pick on specific projects but I can talk about the projects I have experience with.
Example 1: Harbor is a fine registry but the operational setup and requirements are very traditional and not what I would consider to be up to CNCF standards. Editing a config file and running a bash script is not the type of day 1 software experience we should promote. There are also hard coded filesystem paths that are requirements which is a terrible practice even for older software. There is a helm chart for distribution but IMO that's no different than taking any legacy software and putting it into kubernetes. Outside of PKS and the companies listed in adopters I'm also not sure what adoption harbor has had in the broader community.

Example 2: Falco is not integrated into the Linux kernel and my understanding is it never will be. Other options such as kprobes/uprobes appear to be more standard for Linux and the future for kernel level and user level debugging. I'm not at all a Linux kernel developer or intimately familiar with this space but this has been my observation. And don't get me wrong, I love sysdig and falco. I think the UX of sysdig is great and I've used it for 5+ years. I'm just not sure I understand the inclusion of falco with CNCF sandbox projects.

I'm not sure how these aspects should weigh into archiving projects or what "archiving" even means in this context. I would think there would be a way to push the project out of the CNCF umbrella without making them sound like they're no longer maintained which is what I think of when I hear of project archiving.

[philips]

What happens to the intellectual property from an archived project? e.g. trademarks, or copyrights. Is there a doc on that?

[caniszczyk]

@philips no docs yet but current thinking it remains in the LF, just not actively promoted by CNCF

[quinton-hoole]

+1

…

On Sun, Dec 9, 2018, 12:00 Chris Aniszczyk ***@***.*** wrote: @philips <https://github.com/philips> no docs yet but current thinking it remains in the LF, just not actively promoted by CNCF — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#148 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ApoAeFJ_KGDFOH7i0X_rBQif7NL0mvgjks5u3WvHgaJpZM4WGDTW> .

[philips]

What would the process be for a CNCF project to move the IP to a different non-profit?

…

On Sun, Dec 9, 2018, 12:00 PM Chris Aniszczyk ***@***.*** wrote: @philips <https://github.com/philips> no docs yet but current thinking it remains in the LF, just not actively promoted by CNCF — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#148 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACDCD3tcBYPUMer6SbqN0-b4kytcqJfks5u3WvHgaJpZM4WGDTW> .