| Issue 1433: | Request new repository or branch through code review | |
| 26 people starred this issue and may be notified of changes. | Back to list |
As discussed on repo-discuss [1] it would be useful to be able to request, review and approve new repository and branch creations via code review. [1] http://groups.google.com/group/repo-discuss/browse_thread/thread/a5e877e9d2492009#
Jun 25, 2012
Project Member
#1
de...@spotify.com
Jun 25, 2012
Yes, I would suggest that create-project stuff be a special change for All-Projects, perhaps a file on the refs/meta/config branch under the drectory "create-projects/<project>" which contains a config for the proposed new project?
Jun 25, 2012
As for branch changes, they could be under the applicable project's refs/meta/config. Storing it in a file there would work for the intial request, but would get messy when trying to make another change. Instead, perhaps the request should just be in the commit message summary: Request: create branch refs/heads/newbranch <sha1> This branch will be used to work on upstream upbranch destined code
Jun 25, 2012
Another more powerfull approach would be to make a special new magic branch under All-Projects: refs/meta/request Special commits there could be submitted like: SSH: gerrit create-project --name myproject ....
Nov 13, 2012
We talked about this for awhile this morning, and came to the following conclusions: * For requesting branches/tags, you would push to refs/requests/(heads|tags)/<branch|tag name> on the project you're requesting the new branch/tag on. Upon review, the appropriate refs/heads/foo or refs/tags/bar would be created. * For requesting a new project, you could push to refs/for/refs/meta/config on the non-existing project and it would be held for review. This would allow you to request the initial configuration & such for the new repository. Hard parts of this include: * Whether or not it goes ahead and creates the project on-disk, but we didn't come to a firm conclusion (consideration: do we replicate it if so?) * Intercept the "Submit" action since we'll be creating a project/branch/tag instead of actually merging a change to a repo. * How to delete a branch/project (we're looking at the : syntax, but I don't think we're entirely clear how Gerrit would handle that scenario (delete for review? ugh) Things we shot down/punted: * Doing anything regarding group requests yet. Until group info is moved out of the database and into something like All-Groups, any implementation would be hacky and require re-working when All-Groups happen. * Putting everything in the refs/requests/* namespace. It got to be a very nasty rabbit hole of finding a format that supported projects, branches/tags and groups.
Mar 27, 2013
I would also add that having reviews for removing branches would be useful as well.
Mar 28, 2013
Have you considered to make use of the new possibility to include options into the ref syntax [1]? E.g. for requesting a new branch one could push to refs/for/<branch>%request-branch and for requesting a new project one could push to refs/for/refs/meta/config%request-project [1] https://gerrit-review.googlesource.com/42652
Apr 4, 2013
This feature has not had my focus recently, so although I saw the new ref syntax changes get merged I did not consider that the feature would be useful for this. If I make it to the hackahon in May this is one topic that I would like to look into again.
Apr 10, 2013
Issue 1497 has been merged into this issue. |
|
| ► Sign in to add a comment |