Skip to content

bogus initial attempt at describing gerrit #38

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions help
Original file line number Diff line number Diff line change
Expand Up @@ -68,11 +68,11 @@ distribution specific IRC channel which are generally also found on

### Help Us Help You

In any case, please remember that people can only help you if you provide
them enough information. If you have a program dumping core or the operating
system is panicking, then please find some way to make that available. If you
have questions about code that you have written consider making a webrev of your
changes available.
In any case, please remember that people can only help you if you provide them
enough information. If you have a program dumping core or the operating system
is panicking, then please find some way to make that available. If you have
questions about code that you have written consider making a work-in-progress
version of your changes available as a git branch or gerrit code review.

If you are hitting a bug that you do not understand in the compiler, then please
include the full compilation line. In some build systems you may be required to
Expand Down
10 changes: 1 addition & 9 deletions integrating
Original file line number Diff line number Diff line change
Expand Up @@ -67,12 +67,7 @@ submitting your RTI. Furthermore, if there are issues or disagreements about
things between you and your reviewers, that is something that you need to tell
the advocates.

When providing materials for review, the best form of this is a `webrev`. For
information on generating it, please read [the workflow section on
webrev](./workflow.html#webrev). If you have written custom testing software,
you should make that available. This will not only help reviewers better
understand how your changes work, but they will also be able to provide feedback
on the testing and may be able to find cracks in the test plan.
Code reviews are conducted using [gerrit](https://code.illumos.org).

#### Finding Reviewers

Expand Down Expand Up @@ -149,9 +144,6 @@ which checks everything that is in the proto area.

The advocates are going to apply your changes to the gate. As we are using
`git`, the best way to do this is by attaching the output of `git format-patch`.
While `webrev` generates a patch, it isn't always the most useful, as it leads
to people trying to manually add missing files which can be an error prone
process.

If isn't required for you to have merged your changes into the head of the tree,
but if your advocate is doing so and runs into substantial trouble with that,
Expand Down
42 changes: 16 additions & 26 deletions workflow
Original file line number Diff line number Diff line change
Expand Up @@ -559,34 +559,24 @@ The easiest way to do check all of this is to simply run `nightly` again and
look at the contents of the `mail_msg`. If you see errors from there, you will
need to go back and make the appropriate fixes.

### webrev

There are lots of ways that you can share your changes with other people. The
preferred format by the illumos community is that of the webrev(1ONBLD). A
`webrev` is a series of html pages that show the differences and changes in your
code. `webrev` allows people to select various kinds of `diff` formats to use to
look and review your changes. Unlike looking simply at a `diff` or `patch` file,
a `webrev` breaks down the changes on a per-file basis and allows for the reader
to get much more context than normally is possible.

Creating a webrev is easy. All you need to do is make sure that you have your
changes committed locally. It doesn't matter how many commits you have. By
default, all of your uncommitted changes are compared to the head of the tree.
The `webrev` tool has many options for comparing your changes against different
revisions. See the `OPTIONS` section of webrev(1ONBLD) if you need something
other than the default. Otherwise, you can generate a webrev simply by doing the
following while in `bldenv`.

```
$ webrev
$ find /ws/rm/illumos-gate/webrev
$
### Gerrit

Code review for illumos is conducted in [Gerrit](http://code.illumos.org),
it's own
[documentation](https://code.illumos.org/Documentation/user-upload.html)
provides complete details. Briefly, you will push your code to a specially
named branch, which will create the review. Authentication is via your
illumos ssh key in redmine.

```
git push ssh://[email protected]/illumos-gate your-branch:refs/for/master
```

You'll want to share your webrev with your reviewers. If you don't have a place
to upload it or share with them, the illumos community provides some common
places for that which is `cr.illumos.org`. See XXX for more information on
using `cr.illumos.org`.
Will create a review for _your-branch_, and output its URL.
Each commit in your branch will be a separate review, though each will be
grouped together, and each needs a `Change-Id` line, as described in the
Gerrit documentation (the error message should you not do this will tell you
how to enable a hook to create them automatically, should you want to).

### Reviewers

Expand Down