My favorites | Sign in
Project Home Downloads Wiki Issues Source
Search
for
RoadMap  
Ideas and Decisions about the future of Gerrit
Updated Dec 6, 2012 by mf...@codeaurora.org

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.
  • Authentication will eventually be moved entirely to plugins. Much work has already been done on this.
Comment by project member choro...@wikimedia.org, Dec 6, 2012

It might be nice to break this into sections "Near - Medium - Long Term." Then within those we could have sections for things like Architecture, UI, etc.

Comment by project member mf...@codeaurora.org, Dec 6, 2012

I thought about that, but I think for the current content that might just make things more disjointed. If it gets much bigger that might make sense. I actually hope this page doesn't get too big; if it does we should probably just remove stuff. I don't want this to replace the issue tracker, I want this to feel very high level and more of a general guide.

Comment by wer...@beroux.com, Dec 10, 2012

I'm a big fan to the database removal. This will help so much to move repositories around without having Gerrit fail. Just wondering on the planned strategy there for upgrades?

Comment by project member bklarson@gmail.com, Dec 11, 2012

Just curious - what is the benefit of separate repos for all-users and all-groups? Why not use branches in all-projects? I can't think of (many) use-cases for wanting one but not the others.

I don't care much either way, just think that separate repositories might be creating more hassle than benefit.

Comment by Joey.Jia...@gmail.com, Dec 15, 2012

Any planned for JGIT to C-GIT? Suffers a lot path conflict by JGIT merge policy.

Comment by sarojkhamsean@gmail.com, Mar 20, 2013

BENZ

Comment by phil.hord, Jun 8, 2013

+1 for putting all-users and all-groups into all-projects. "Users shouldn't be able to access other users prefs" is fine, but please do not consider this a secure storage without some encryption. Ditching the DB makes it possible for Gerrit to be a distributed code review system (dcrs). I have teams writing code at other companies and I would like to share some of our projects with them. In some cases I want to share only some of our branches with them. In both of those cases, I would like to share some of our user names with them. And so on. I think this is beginning to sound like MultiMaster, though.

Comment by project member mf...@codeaurora.org, Jun 12, 2013

bklarson: your point is good. I thought we had a solid reason for it, but I am not sure. I think some of the resoning was that All-Projects tends to be a place to store server-wide policy and if we could move projects from one server to another, you would not likely move All-Projects however you might want to copy (or somehow merge) the All-Users and All-Groups repos from one server to another? I think that you are right though and we should have a clear reason for doing it if we do. If we need to discuss more, let's create an issue for it, or discuss on ML...

Comment by lizao...@gmail.com, Jul 17, 2013

great job

Comment by metuxits...@googlemail.com, May 22, 2014

Does Gerrit already support branch hierachies ?

Lets assume we have an topic A, which requires topic B, and that again requires C and D. Now I'd like to mature all topics for a while, until they're allowed to finally go to mainline - honoring the dependencies, of course. And of course it needs to cope well with changed history within the individual topics (amending, squashing, etc).

Does Gerrit already support such scenarios ?

The only tool I know, claiming to support that, is accurev.

Comment by tomas.pr...@gmail.com, Oct 4, 2014

And what about GIT history viewer with possibility do commit review for oldest commits (like GitHub? or BitBucket?). Sometimes is merged something what was good during review time, but it is not good now.

Comment by wilsonmatthew1988@gmail.com, Feb 28, 2015

Nb

Comment by rye.uzum...@gmail.com, Dec 22, 2015

I am very happy to read an article on this website, this article is very satisfying for the reader, thanks for the enlightenment that has been described in this article. http://www.carquotereviews.com/2015/11/read-extended-car-warranty-reviews-before-your-choose-best-protection-for-car.html


Sign in to add a comment
Powered by Google Project Hosting