# Introduction

There are many ideas suggested, and discussions which lead to decisions about
the future direction and designs of Gerrit which happen in many forums: on IRC,
the ML, at the hackathons, and in the issue tracker. It can be hard for an
outsider to get a feel for where Gerrit might be headed in the near, medium, and
long term. Of course, since this is an open source project, code speaks loudly.
However there are times when the maintainers feel that certain pathes are not
the way forward, and the desired alternative may have already been proposed as
the way that Gerrit should move. It can be helpful to developers to get an idea
about these decisions before embarking on developping a feature. Naturally,
there are also times when people just want to get a feel for what might be
coming down the pike. So we will attempt to illustrate some of these decisions
here.

# Architecture

*   The REST API is viewed as the longterm stable approach for RPCs with the
    Gerrit Server. At this point new UI elements and new ssh commands should be
    developed against it. If a new service is created, it should extend the
    current REST API or implement new pieces.

*   The hooks will eventually be moved to plugins.

*   The Database will eventually be removed from Gerrit. Authoritative data will
    mostly be pushed into the project repositories. An indexing service such as
    Lucene will be used to provide fast access to data. While this is the long
    term plan, some pieces have already been moved out of the DB and into the
    repos, for example project configuration and ACLs. Newer features are
    expected to take a similar approach when possible.

*   New user preferences should be placed in a (yet to be born) repo named
    All-Users. Each users preferences will live in a gitconfig style file under
    a reference named refs/users/xxx/accountid where xxx is accountId mod 1000.
    Since users shouldn't be able to access other users' refs, this structure
    can be hidden from them and they should be able to access their refs via
    refs/heads/master

*   Groups should probably gain a similar All-Groups repo. The membership file
    could live there. See the [gitgroups plugin]
    (https://gerrit-review.googlesource.com/35780).

*   Authentication will eventually be moved entirely to plugins. Much work has
    already been done on this.