[kinto] To merge or not to merge

Ethan Glasser-Camp eglassercamp at mozilla.com
Wed May 11 12:28:04 UTC 2016


Hi community,

As a result of Cliquet#687 (
https://github.com/mozilla-services/cliquet/issues/687), we have been
discussing the future of Cliquet and Kinto.

To summarise the issue, we have identified the following problems:

* Cliquet adds an abstraction level that leads to some confusion for our
users in Kinto [0]
* Maintaining documentation between both projects is hard. Kinto
documentation is limited because of this split and the fact that we copy
parts of the cliquet documentation into the kinto documentation.
* Cliquet has concepts that are not used by Kinto (nor probably by anybody
yet)
* Newcomers are sometimes confused when a bug/feature is to be implemented
in Cliquet rather than Kinto
* We have a chance to build a community around Kinto, and probably not with
Cliquet. We should make sure not to lower the potential of the former
because of the latter ;)
* Indeed, Cliquet has no community on its own and is supported by the Kinto
community.

It seems to us that it is complicated to grasp the relationship between
Cliquet and Kinto and even harder to know if an issue is related to Cliquet
or Kinto.

We believe that the current strategy for our users is that if you plan on
doing some storage you should probably start with the Kinto service. Once
you hit a limitation that cannot be fixed using a Kinto plugin, you can
build your own server on top of cliquet.

That is the reason why, last summer, we started a discussion about renaming
cliquet to "kinto core". In this way, you do not have to leave kinto for
cliquet — you stay in the kinto ecosystem, just using it as a library
rather than a service. This lets us get rid of the confusion about what the
difference is between cliquet and kinto. We would keep the two levels of
"instantiation": one for the "kinto core" and its boilerplate (utility
views, backends, etc.), and another one for "kinto" and its endpoints
(bucket/collections/records, etc.)

But as discussed in the Github issue, there are two ways we can make this
change: we can simply change the name of the cliquet repo (and package,
etc.), or we can merge it into the kinto repo. We have listed pros and cons
for these two solutions:

Solution #1: rename mozilla-services/cliquet to Kinto/kinto_core
Pros:
* Rather easy (matter of search/replace)
* Github issues and history are conserved
* URL redirection is automatic
* Makes it easier for a user to understand what cliquet is and how it
relates to Kinto, and lets us simplify the docs somewhat (because kinto can
link to kinto-core without confusing users)

Cons:
* Does not solve as many indirection / documentation and release problems

Solution #2: merge cliquet into kinto repo
Strategy:
* Merge Cliquet into the Kinto repo to preserve version history
* Duplicate Github issues into the Kinto repository to ensure they are
still addressed

Pros:
* Less indirection
* Less concepts, less confusion
* Less release overhead
* Many abstractions of Cliquet are unused and can be removed/simplified
* No more hacks for documentation (like copy cliquet docs to a subfolder
etc [1])
* Helps to keep things at the same place: documentation, issue tracking

Cons:
* Bigger kinto repo
* Requires a lot of energy :)
* Risk that the separation between a generic resource and its usage in
Kinto becomes blurry
* If a new project comes up, using kinto.core is going to be less intuitive
than using generic resources of Cliquet
* If a new project comes up, it will depend on the entire kinto package
even though it doesn't use its views

Either way, once we identify the way forward, we have to:
* write a blog post explaining what happened to the Cliquet library we were
so excited about
* add a banner to the Cliquet repo pointing to that blog post and
explaining that it's deprecated
* release a new major version of Kinto (since all its plugins will have to
change)
* migrate plugins using some compat/fallback code for current cliquet
dependency
* keep the old repo at the old name and use it for maintenance versions

In our opinion, the second approach provides more benefits, but we would
like your feedback before we make this drastic change. What do you think?


Thanks for reading this long email. We are looking forward to your feedback.

The storage team.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/kinto/attachments/20160511/b0fd7560/attachment.html>


More information about the Kinto mailing list