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.
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.
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.
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?
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.
Any planned for JGIT to C-GIT? Suffers a lot path conflict by JGIT merge policy.
BENZ
+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.
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...
great job
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.
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.
Nb
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