Gerrit 2.2.2 "roadmap"
Shawn Pearce
the Prolog interpreter support and use it to decide if a change is
submittable in a project. This provides us with some simple
per-project workflow logic.
I'm waiting on a few things to be written and merged, and then I will
ship 2.2.2:
* Compile Prolog rules to Java bytecode. The Prolog interpreter we are
using (a fork of Prolog Cafe) supports compiling Prolog code to Java
bytecode, making evaluation significantly faster at runtime. We
already have support for loading pre-compiled bytecode from the
$site_dir/cache/rules directory, but we don't have an easy way to
create these cached JAR files. In 2.2.2 we will have a `java -jar
gerrit.war rulec` tool to support site administrators building a rule
JAR. These rule JARs could be built on a development system, and then
copied to a production system (for example). My intern Jason is
working on this feature and should finish it up soon. In 2.2.3 I hope
to make this a dynamic feature of the server itself, where the server
can recompile modified rules if the JDK is installed.
* Surface the Prolog can_submit decisions in the web UI. Currently the
web UI does not update to reflect what the Prolog rules for a project
state is required for a change to be submittable. We need to surface
this data on the top level Change page, as part of the approvals table
and the bulleted list right below it. We also need to put this on the
Publish Comments page, so reviewers know which radio buttons they
should try to check in this project, and which ones they don't
actually need here.
* Expose more change data to the Prolog rules. Right now the only data
exposed to the Prolog rules is the approvals that were made by
reviewers. This should be expanded to include anything that is usable
as a search operator, including affected files, author, branch name,
etc.
* Rule inheritance (optional). I haven't yet figured out how we will
do rule inheritance via the parent project references. So I may ship
2.2.2 without this feature. But its necessary, because in some of my
servers I need to set default rules in All-Projects that everyone must
adhere to, in addition to their own per-project rules.
Pierre Tardy
Just a heads up on where Gerrit 2.2.2 will be. We have already merged
the Prolog interpreter support and use it to decide if a change is
submittable in a project. This provides us with some simple
per-project workflow logic.
Shawn Pearce
> On Mon, Jun 20, 2011 at 4:09 AM, Shawn Pearce <s...@google.com> wrote:
>>
>> Just a heads up on where Gerrit 2.2.2 will be. We have already merged
>> the Prolog interpreter support and use it to decide if a change is
>> submittable in a project. This provides us with some simple
>> per-project workflow logic.
>
> resolve,
We are trying to support custom project workflows. Different projects
on the same server may have different ways to determine if a change is
submittable to that project. For example, within Android the Google
development team goes into a "feature freeze" mode where an additional
level of approval is required to submit changes just before a release
gets made. At the Eclipse Foundation, changes not written by a project
committer need to go through an legal review process if the change is
longer than 250 lines of code. For a linux kernel repository, a change
must have a Signed-off-by line by the author of the change. Etc.
We want to formalize the logic into a rule that Gerrit Code Review can
execute and enforce for the project, rather than relying on humans all
of the time.
> and why prolog is better than procedural to solve it.
Most of the rules we need are actually simple boolean expressions.
These are pretty easy to write in Prolog. (Or really in any other
language for that matter.) Where Prolog shines over a lot of
procedural languages is its ability to backtrack through the
expression tree and try alternative routes. This makes it easy for the
rule-writer to construct a rule that allows the UI to give us good
information about what is required in the expression to make the
change submittable. It can also tell us the expression is impossible
to make true, due to insufficient permissions being granted, etc.
I want to use the Prolog interpreter + rules to also be a
recommendation system for reviewers. The interpreter can tell us which
reviewers are able to set the necessary labels to make this change
submittable, and thus can also recommend to us which reviewers we
should add to a change. A lot of this seems to come "for free" with
relatively little effort on the part of the rule writer.
Doing the same sort of thing in a procedural language seemed to
require a lot more effort on the part of the rule writer. I suspected
most rule writers wouldn't bother, or would try to side-step the
recommended best-practices in order to write a shorter rule, but
resulting in a worse user experience. Since Prolog provides a lot of
this for free, it makes it more likely a rule writer won't side-step
the user experience.
I actually mocked out some example rules in Python, JavaScript, Java,
Scala and Prolog. The Scala and Prolog ones kept coming up shorter.
The Prolog ones were slightly better in that the language is very
simple and easy to process ourselves in memory, making it possible to
do introspection on the rule body if we need to.
Most rules will probably be written in the Gerrit query language and
converted to Prolog by the server. We aren't there yet, but I suspect
that is where we will be going. If you need more functionality than
what the query language can offer, you would need to start writing
some Prolog.
> What kind of customization will be left to us in the UI?
I'm not sure I understand the question. Are you asking if we will
support customizing the workflow from within the web UI? Not
initially. Workflow changes will need to be made by Prolog rule
changes applied to the "rules.pl" file in the refs/meta/config branch,
and pushed manually by the project owner or site administrator.
Eventually we will support some form of editing rules from the web UI,
but this might only ever support the query language variant that is
more limited.
> Will the user be needed to write prolog to configure its workflow?
Probably. But we are talking about a couple of lines of Prolog for
most uses. Its so short, you probably won't realize its Prolog.
> Will the mergeable appear in the changeDetail json interface?
Yes, this is one of the things on the roadmap, implicitly anyway. I
need to export some of the results from the Prolog interpreter into
the JSON that we feed the web UI.
> Will the submit button not appear in the UI if not mergeable?
This is a bug in the current 2.2.x series. The button is showing up
all of the time now, rather than just when the change is submittable.
We should eventually fix this, but maybe we won't. Hiding UI widgets
that you can't currently activate makes it hard to know why that UI
widget is missing from the UI. If its always there, you can click it
and get a dialog box telling you why you can't click it right now...
and what you can do to make that action work (e.g. add a reviewer, ask
a current reviewer to approve, etc.).
> Will the not mergeable reason be clearly available in the UI?
Yes, that is sort of the point of this.
> Shall we move to git submodules to fully make use of this?
I have no idea how using git submodules is related to the extended
workflow concepts.
Mihai Rusu
> This is a bug in the current 2.2.x series. The button is showing up
> all of the time now, rather than just when the change is submittable.
> We should eventually fix this, but maybe we won't. Hiding UI widgets
> that you can't currently activate makes it hard to know why that UI
> widget is missing from the UI. If its always there, you can click it
> and get a dialog box telling you why you can't click it right now...
> and what you can do to make that action work (e.g. add a reviewer, ask
> a current reviewer to approve, etc.).
A tool tip on a "deactivated" Submit button could provide the same
information. But your idea sounds fine too IMO.
--
Mihai Rusu
Shawn Pearce
Yes, you are right. We should show the button, but disable it and use
a tooltip to let the user know what is wrong. Great idea!
Eric Anderson
--To unsubscribe, email repo-discuss...@googlegroups.comMore info at http://groups.google.com/group/repo-discuss?hl=en
Shawn Pearce
> These rules will be applicable per repo in gerrit?
Yes. Right now the rules are per-repository (aka per-project).
Eventually I'll figure out how to do inheritance, and they can also
inherit down from parents like All-Projects, providing site-wide
rules.
Pierre Tardy
We are trying to support custom project workflows. Different projects
on the same server may have different ways to determine if a change is
submittable to that project.
I have no idea how using git submodules is related to the extended
workflow concepts.