RFC: Sustainability of TensorFlow Addons #84
Conversation
This document details requirements and responsibilities for owning a subpackage/submodule that is included in TensorFlow Addons, as well as the periodic review process for all components of Addons. Created by Sean Morgan (@seanpmorgan), Yan Facai (@facaiy), Paige Bailey (@dynamicwebpaige).
dynamicwebpaige
requested review from
goldiegadde and
martinwicke
as code owners
ewilderj
changed the title
|
One of the main issue about addons/plugins systems is how you can quickly be aware on what addon you could rely expecially in produciton (without manually checking ticket lag, commit activity etc..). |
Sounds great. That's why we propose a periodic review process for all components of Addons. @seanpmorgan @dynamicwebpaige What do you think, Sean, Paige? |
| 3. Amount of issues or bugs attributed to the code | ||
|
|
||
| Because we encourage TF-Addons to be used in production, we'll plan on a | ||
| graceful deprecation process, instead of a swift removal. |
There was a problem hiding this comment.
similar here, should we define what is graceful in this case. Could be too early, but potentially very valuable promises for people introducing addons in production
There was a problem hiding this comment.
Yeah, this is probably better done sooner rather than later. I do think we'll reserve deprecating things unless they're truly unused in the community at least for a while.
There was a problem hiding this comment.
explicit is better than implicit ;)
There was a problem hiding this comment.
Agreed that "explicit is better than implicit".
IMHO, "deprecation" can come from different reasons, eg if the lib is short of maintenance/full of bug, or a better solution is available to solve the same problem, which makes the current API less useful.
I think API can be categorized into 3 groups: Suggested/Discouraged/Deprecated.
Suggested: Well maintained API and encourage user to use.
Discouraged: Better alternative is available, the API is kept for historical reason; or just in the waiting period to be deprecated; or the API is short of maintenance, which might cause issue in prod.
Deprecated: Use at your own risk, subject to be deleted after certain peroid.
The status change between these three is: Suggested <-> Discouraged -> Deprecated
The period between an API being marked as deprecated and being deleted can be 90 days.
- If addons does release monthly, there will be 2-3 releases before an API is deleted. The release notes could give user enough warning.
- It is not too long comparing to 180 days, nor too short as 30 days, so that people can fix their code.
- Google project zero uses 90 days window for security fix, which is a trade off between risk and time to respond. For more comparison of different time window, please see https://googleprojectzero.blogspot.com/search?q=90+days.
Also we should be mindful the amount of Discouraged API. They should either be fixed, or move to deprecated. Keeping Discouraged API will make long tail and cause the repo hard to maintain.
There was a problem hiding this comment.
I think this is a solid plan... would you like to submit a modification to this PR? Not sure if you have access to the branch, but @dynamicwebpaige should be able to help.
There was a problem hiding this comment.
I think its fine for either you or Paige to just update the PR.
There was a problem hiding this comment.
Updating now! And very much like the plan for Suggested -> Discouraged -> Deprecated. 👍
| 3. Amount of issues or bugs attributed to the code | ||
|
|
||
| Because we encourage TF-Addons to be used in production, we'll plan on a | ||
| graceful deprecation process, instead of a swift removal. |
There was a problem hiding this comment.
We discussed the idea of a 2 phase deprecation process during the monthly meeting. We mark modules as "Going to be removed if nobody responds" or something similar. After half a year we do a "spring cleanup" and code that is not needed anymore will be removed. What do you think?
There was a problem hiding this comment.
Agree. @qlzh727 described a 3 phase system after this post that I think gives us even more flexibility.
|
In terms of process, shall we consider the next SIG Addons meeting as the final review for this RFC and have it finalized and moved to "Accepted" after that meeting? @seanpmorgan ? |
SGTM! 👍 |
|
Per today's team call, please push an update changing status to Accepted, and I will merge |
ewilderj
added
RFC: Accepted
|
Thanks everyone, congrats on the finalized RFC! |
Comment period ends 2019-04-08
Sustainability of TensorFlow Addons
Objective
TensorFlow Addons is a repository of contributions that conform to well-established API patterns, but implement new functionality not available in core TensorFlow. For TensorFlow Addons to support code that is moved from
tf.contribtoaddons, as well as new functionality, requirements for maintaining and retiring those submodules must be defined and enforced.This document details requirements and responsibilities for owning a subpackage/submodule that is included in TensorFlow Addons, as well as the periodic review process for all components of Addons.
In this RFC, we are soliciting discussion regarding Addons maintainership and periodic review. This RFC discussion will help the SIG Addons team determine appropriate roles and responsibilities for proxy maintainers.