<commit_before># Standalone Keras Repository

| Status        | Proposed |
:-------------- |:---------------------------------------------------- |
| **RFC #**     | [202](https://github.com/tensorflow/community/pull/202) |
| **Author(s)** | <NAME> (<EMAIL>), <NAME> (<EMAIL>) |
| **Sponsor**   | <NAME> (<EMAIL>) |
| **Updated**   | 2020-02-05                         |

## Objective

Move the Keras code from the TensorFlow main GitHub repository to its own
repository, with TensorFlow as a dependency.

## Motivation

### Build times

Building the open-source TensorFlow project end-to-end is an extensive exercise. 
With a standard GCP instance, it might take more than one hour to finish the whole
build process (it might take longer with a Mac laptop). Although the local build 
cache might help speed up the follow-up builds, the initial time cost is too 
high for regular software development workflows. Internally, Google has a
distributed build and caching service, which Googlers heavily rely on,
that can build TensorFlow and run all Keras tests within 5 mins. Sadly,
we can't expose this to external contributors.

Currently, any contribution to Keras code will require building all of
TensorFlow, which is quite expensive to do for average users.
Having a separate repository will allow the Keras package to be built
without building TensorFlow. This should greatly improve the 
velocity of open-source developers when they contribute to Keras code.

### Community Benefit

The difficulty of building TensorFlow from scratch in order to make a PR
to Keras code has been a significant source of issues:

* It discouraged contributions, since many external developers couldn't test
their changes and make sure they were correct.
* External developers would send unverified PRs, and Google reviewers spend time back 
and forth, fixing the PR. Sometimes PR is just not moving forward because of the
lengthy feedback loop.

With the new standalone Keras repository, external contributors
should experience much shorter turn-around time when 
building/testing Keras, since they don't need to build TensorFlow anymore.
This should  have a positive impact on building a vibrant open-source
developer community.

In addition, by getting the Keras team at Google to start developing Keras
using the same public tools and infrastructure as third-party developers,
we make the development process more transparent and more community-oriented.

### TensorFlow API modularity

There are other side-benefits if we split the repository. Currently, Keras
has to rely on a number of private TensorFlow APIs. However, a litmus test
of the quality of the public TensorFlow low-level APIs is that they should
be strictly sufficient to a higher-level API like Keras.
After splitting the repository, Keras will have to import TensorFlow and 
rely exclusively on public APIs. If Keras still ends up using TensorFlow
private features, it  might be an indication of tight coupling of
implementation details. If certain private features are extensively used,
we might want to consider exposing them  as public low level API.

This design is also aligned with the design for
[Modular TensorFlow](https://github.com/tensorflow/community/blob/master/rfcs/20190305-modular-tensorflow.md), 
which splits the TensorFlow project into smaller components that are not
tightly coupled together.


## Design Proposal

### New location of the code

GitHub: the code will live at [keras-team/keras](https://github.com/keras-team/keras), 
joining the other Keras SIG projects and replacing the current external Keras 
codebase. `tf.Keras` will also replace Keras on PyPI.

Also considered: `tensorflow/keras`.

Pros:
1. Under the umbrella of Keras SIG, which hosts all other Keras related projects
like keras-application, KerasTuner etc.
1. Lots of existing followers on keras-team, who may not be easily migrated to 
TF project.
1. Can't easily delete keras project, which already have tons of stars and 
incoming reference links. Continued existence of external Keras code will create
confusion ("why is there tensorflow/keras AND keras-team/keras?").

Cons:
1. The repo isn't under the same organization as tensorflow, which makes it hard
to manage issues/PRs and references across the organization.
1. Existing issue/PR under the same org can be transferred easily, but not cross the different org. See [here](https://help.github.com/en/github/managing-your-work-on-github/transferring-an-issue-to-another-repository).

### Source of Truth

TensorFlow uses a Google-internal code repository as its source of truth. Every PR
submitted though GitHub is converted to a Google-internal change first,
submitted through the internal system, and then copied to GitHub as commits.
At the same time, PR is marked as merged with the corresponding commit hash.

Likewise, issue tracking and code review takes place through Google-internal tools.

For Keras, since we are trying to promote community engagement, we hope to use 
GitHub as source of truth. This will have the following implications:

* We expect the majority of the code development/contribution from GitHub
and the dev tools / tests / scripts should focus on the GitHub development use
case. See below for more details.
* Keras CI/presubmit build for the GitHub repo should target a stable PIP 
version of tensorflow package as dependency. It could either be a `tf-nightly`
with explicit version, or a release candidate version, or a stable version.
Depend on a floating `tf-nightly` could cause CI build to be instable, which has
been observed in other repository 
[like tf-addons](https://github.com/tensorflow/addons/pull/912).
* The Keras code will be mirrored to a Google-internal code repository via
Google-internal tools within a very short time window after each change.
The Google-internal CI tests will run on HEAD for both Keras and TF code.
* The CI build for the repository on GitHub might break when it points to a
new version of `tf-nightly`, if certain behavior has been changed and wasn't
caught by unit tests. We have observed a few similar cases with
[tf/addons](https://github.com/tensorflow/addons).
We hope this can be reduced by stronger unit test coverage by Google internel
systems, when both TF and Keras code are tested at HEAD.
* pip package management. Keras will now follow the `tf-estimator` approach. 
"pip install tensorflow" should also install Keras (from PyPI) as well.
There are more details for the pip package in the
[Improved pip package structure](https://github.com/tensorflow/community/pull/182) RFC.
<commit_msg>Update the preferred PIP package version.<commit_after># Standalone Keras Repository

| Status        | Proposed |
:-------------- |:---------------------------------------------------- |
| **RFC #**     | [202](https://github.com/tensorflow/community/pull/202) |
| **Author(s)** | <NAME> (<EMAIL>), <NAME> (<EMAIL>) |
| **Sponsor**   | <NAME> (<EMAIL>) |
| **Updated**   | 2020-02-05                         |

## Objective

Move the Keras code from the TensorFlow main GitHub repository to its own
repository, with TensorFlow as a dependency.

## Motivation

### Build times

Building the open-source TensorFlow project end-to-end is an extensive exercise. 
With a standard GCP instance, it might take more than one hour to finish the whole
build process (it might take longer with a Mac laptop). Although the local build 
cache might help speed up the follow-up builds, the initial time cost is too 
high for regular software development workflows. Internally, Google has a
distributed build and caching service, which Googlers heavily rely on,
that can build TensorFlow and run all Keras tests within 5 mins. Sadly,
we can't expose this to external contributors.

Currently, any contribution to Keras code will require building all of
TensorFlow, which is quite expensive to do for average users.
Having a separate repository will allow the Keras package to be built
without building TensorFlow. This should greatly improve the 
velocity of open-source developers when they contribute to Keras code.

### Community Benefit

The difficulty of building TensorFlow from scratch in order to make a PR
to Keras code has been a significant source of issues:

* It discouraged contributions, since many external developers couldn't test
their changes and make sure they were correct.
* External developers would send unverified PRs, and Google reviewers spend time back 
and forth, fixing the PR. Sometimes PR is just not moving forward because of the
lengthy feedback loop.

With the new standalone Keras repository, external contributors
should experience much shorter turn-around time when 
building/testing Keras, since they don't need to build TensorFlow anymore.
This should  have a positive impact on building a vibrant open-source
developer community.

In addition, by getting the Keras team at Google to start developing Keras
using the same public tools and infrastructure as third-party developers,
we make the development process more transparent and more community-oriented.

### TensorFlow API modularity

There are other side-benefits if we split the repository. Currently, Keras
has to rely on a number of private TensorFlow APIs. However, a litmus test
of the quality of the public TensorFlow low-level APIs is that they should
be strictly sufficient to a higher-level API like Keras.
After splitting the repository, Keras will have to import TensorFlow and 
rely exclusively on public APIs. If Keras still ends up using TensorFlow
private features, it  might be an indication of tight coupling of
implementation details. If certain private features are extensively used,
we might want to consider exposing them  as public low level API.

This design is also aligned with the design for
[Modular TensorFlow](https://github.com/tensorflow/community/blob/master/rfcs/20190305-modular-tensorflow.md), 
which splits the TensorFlow project into smaller components that are not
tightly coupled together.


## Design Proposal

### New location of the code

GitHub: the code will live at [keras-team/keras](https://github.com/keras-team/keras), 
joining the other Keras SIG projects and replacing the current external Keras 
codebase. `tf.Keras` will also replace Keras on PyPI.

Also considered: `tensorflow/keras`.

Pros:
1. Under the umbrella of Keras SIG, which hosts all other Keras related projects
like keras-application, KerasTuner etc.
1. Lots of existing followers on keras-team, who may not be easily migrated to 
TF project.
1. Can't easily delete keras project, which already have tons of stars and 
incoming reference links. Continued existence of external Keras code will create
confusion ("why is there tensorflow/keras AND keras-team/keras?").

Cons:
1. The repo isn't under the same organization as tensorflow, which makes it hard
to manage issues/PRs and references across the organization.
1. Existing issue/PR under the same org can be transferred easily, but not cross the different org. See [here](https://help.github.com/en/github/managing-your-work-on-github/transferring-an-issue-to-another-repository).

### Source of Truth

TensorFlow uses a Google-internal code repository as its source of truth. Every PR
submitted though GitHub is converted to a Google-internal change first,
submitted through the internal system, and then copied to GitHub as commits.
At the same time, PR is marked as merged with the corresponding commit hash.

Likewise, issue tracking and code review takes place through Google-internal tools.

For Keras, since we are trying to promote community engagement, we hope to use 
GitHub as source of truth. This will have the following implications:

* We expect the majority of the code development/contribution from GitHub
and the dev tools / tests / scripts should focus on the GitHub development use
case. See below for more details.
* Keras CI/presubmit build for the GitHub repo should target a stable PIP 
version of tensorflow package as dependency. It could either be (preferably in
this order):
  * a stable version
  * a release candidate version
  * a `tf-nightly` with explicit version.
Using a nightly version for testing should be motivated by the usage of a API
feature not present in the stable or pre-release version.
Depend on a floating `tf-nightly` could cause CI build to be instable, which has
been observed in other repository 
[like tf-addons](https://github.com/tensorflow/addons/pull/912).
* The Keras code will be mirrored to a Google-internal code repository via
Google-internal tools within a very short time window after each change.
The Google-internal CI tests will run on HEAD for both Keras and TF code.
* The CI build for the repository on GitHub might break when it points to a
new version of `tf-nightly`, if certain behavior has been changed and wasn't
caught by unit tests. We have observed a few similar cases with
[tf/addons](https://github.com/tensorflow/addons).
We hope this can be reduced by stronger unit test coverage by Google internel
systems, when both TF and Keras code are tested at HEAD.
* pip package management. Keras will now follow the `tf-estimator` approach. 
"pip install tensorflow" should also install Keras (from PyPI) as well.
There are more details for the pip package in the
[Improved pip package structure](https://github.com/tensorflow/community/pull/182) RFC.

{'fraction_non_alphanumeric': 0.06394913986537024, 'fraction_numerical': 0.0050860134629768135, 'mean_word_length': 4.206775700934579, 'pattern_counts': {'":': 0, '<': 15, '<?xml version=': 0, '>': 15, 'https://': 14, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6261658', 'n_tokens_mistral': 3452, 'n_tokens_neox': 3261, 'n_words': 1863}