We’ve spent a lot of effort making TensorFlow more modular and optimizing the dependency surface between Keras and TensorFlow. One of the milestones we’ve reached is that Keras code is being split to its own repository, github.com/keras-team/keras (more details about the move can be found in the RFC). This enables Keras to use the Tensorflow Python API as a PIP package dependency without having to compile TensorFlow when building and testing. One of the biggest benefits of this change is that running Keras Bazel tests locally now only takes a few minutes, instead of several hours (mostly spent compiling Tensorflow).
Any previously outstanding active Keras-related PR in github.com/tensorflow/tensorflow will be merged manually into github.com/keras-team/keras after approval (Keras team members will do the sync and merge internally, no action needed on the author’s side). However, if the PR has been open for a long time and lacks activity from the author, we may simply close it.
We hope this is not a common case, since Keras is actually on top of Tensorflow, and based on change history internally, we don’t observe this case a lot.
Yes it seems only 18.5%. Is this related to PR (so to user contribution) or to internal commits?
As I suppose that some features internally could be exposed in Tensorflow and not also to Keras in the same commit.
Anyway, in the end, beyond what the actual estimate of cases is, let’s try to manage them as best we can because it might be a criticality point since Keras is again a python-only standalone respository now.
E.g. Just like when you need to introduce an Op or a layer that you cannot solve efficetntly with a TF API compositional approach.
This is same for both internal commit and external PR. Internally we do test against PIP package as well, which means a change can’t reach TF and Keras at same time.
We understand that any change that touch both TF and Keras could be hard to manage, and we will try our best to push forward those changes if it depends on the change in the other repo.
In the meantime how the new Keras tickets in TF are triaged (and vice versa)?
As we are in two different GitHub org I think that we cannot move the ticket across repos.
I don’t think so as that the API golden path is still tensorflow.keras. So formally, if I am not wrong, Keras is still an API in the tensorflow namespace:
Probably what it is interesting is to know if this API in the TF namespace will be under an independent Governance with:
Or if major changes will go through the RFC community process as TF and other SIGs:
User should always use “from tensorflow import keras” which will give them the public API.
“import keras” will directly access the keras PIP package, which is not 100% same as the public API namespace. It will probably give you keras.Model/layers.* etc, but not all the APIs. Under the hood, we populate all the APIs under keras/api/* and tensorflow init files will pick them up from there.
