On 12/15/2014 12:13 PM, Amit Saha wrote:

Scenario: Create a fork of an upstream project whose source is on github

Steps:

1. Fork the project as beaker-project's upstream on GitHub
2. Login to beaker-project.org
3. Init a bare git repo on /srv/git/: git init --bare --shared <project_name>
4. chown -R <username>:beakerdevs /srv/git/<project_name>
5. Setup the project on http://gerrit.beaker-project.org/#/admin/create-project/, inherit permissions from beaker project
6. Setup DENY permission for Fedorahosted replication authgroup
7. Push the master branch of upstream fork to gerrit: git push restraint-gerrit master

Thanks Amit. Would you mind adding that to the developer guide somewhere?

Cheers, Nick.

Excerpts from Amit Saha's message of 2014-12-15 12:13 +10:00:

Scenario: Create a fork of an upstream project whose source is on github

Steps:

1. Fork the project as beaker-project's upstream on GitHub
2. Login to beaker-project.org
3. Init a bare git repo on /srv/git/: git init --bare --shared <project_name>
4. chown -R <username>:beakerdevs /srv/git/<project_name>
5. Setup the project on http://gerrit.beaker-project.org/#/admin/create-project/, inherit permissions from beaker project
6. Setup DENY permission for Fedorahosted replication authgroup
7. Push the master branch of upstream fork to gerrit: git push restraint-gerrit master

Steps 2-7 are essentially the process for creating any new git repo to be hosted on b-p.o and so it would be good to write those down in the dev docs about b-p.o.

As for forking other repos: we still don't have a good answer about how we can use Gerrit for reviewing our own patches while still submitting sane pull requests to other repos. The issue is that our patches will end up on master but you really need to send pull requests from feature branches, not from master. This is something we will need to work out. We have not been doing a very good job of it with lshw so far.