Gerrit newbie question: non-administrators creating projects?

[Larry Prikockis]

apologies if my question stems from an incomplete grasp of the philosophy/best-practices of Gerrit/git...

Is there a way to allow users to be able to create a new project (either thru the web gui or ssh) without them being in the Administrators group?  

It seems like there are cases where we'd want engineers to be able to create a new project themselves in Gerrit-- but obviously it doesn't make sense to put everyone in the Administrator group.

I feel like I'm missing some core understanding of Gerrit since I haven't seen anyone else discussing this as a problem.

any clues appreciated ;-)

[Edwin Kempin]

Hi Larry,

you can allow users to create projects by assigning the global create project capability [1] to a group.
Global capabilities are assigned in the access rights of the root project (normally 'All-Projects').
This capability is available since Gerrit 2.2.2 [2].

Project creation through the WebUI is supported since Gerrit 2.3 [3].

Best regards,
Edwin

[1] https://gerrit-review.googlesource.com/Documentation/access-control.html#capability_createProject
[2] http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.2.2.html#_config
[3] http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.3.html#_web

2012/4/27 Larry Prikockis <thirs...@gmail.com>

--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

[Larry Prikockis]

D'oh!

thanks for clarifying that! much better now...

--
Check out http://vecnamed.blogspot.com/
"Getting to Zero:  A Campaign to reduce Health-care Acquired
Infections in Clinical Settings"

[Magnus Bäck]

On Friday, April 27, 2012 at 08:09 EDT,

While there certainly are cases where it's reasonable to have mortal
users create projects, make sure you're allowing it for the right
reason. Users coming from other hosting platforms might be under the
impression that creating their own project clone to work on an existing
project is the right way of doing things.

On the practical side, since renaming projects probably is a hassle it
might make sense to have an administrator or some other senior engineer
vet the project names first.

--
Magnus Bäck
ba...@google.com

[Martin Fick]

On Friday, April 27, 2012 09:59:08 am Magnus Bäck wrote:
> On the practical side, since renaming projects probably
> is a hassle it might make sense to have an administrator
> or some other senior engineer vet the project names
> first.

Yeah, a nice way to submit project creation for review would
be cool! :) Any thoughts on how Gerrit could do that?

-Martin


--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum

[Martin Fick]

On Friday, April 27, 2012 10:02:43 am Martin Fick wrote:
> On Friday, April 27, 2012 09:59:08 am Magnus Bäck wrote:
> > On the practical side, since renaming projects probably
> > is a hassle it might make sense to have an
> > administrator or some other senior engineer vet the
> > project names first.
>
> Yeah, a nice way to submit project creation for review
> would be cool! :) Any thoughts on how Gerrit could do
> that?

For that matter, I think I recall someone requesting a way
to review branch creation also. Perhaps what we need is
some sort of pseudo changes. We could have a CREATE_PROJECT
pseudo change and a CREATE_BRANCH pseudo change, perhaps a
DELETE_BRANCH also?

[Edwin Kempin]

+1 for being able to request, review and approve the creation/deletion of projects, branches, groups etc.

2012/4/27 Martin Fick <mf...@codeaurora.org>

[Magnus Bäck]

On Friday, April 27, 2012 at 12:02 EDT,

Martin Fick <mf...@codeaurora.org> wrote:

> On Friday, April 27, 2012 09:59:08 am Magnus Bäck wrote:
> > On the practical side, since renaming projects probably
> > is a hassle it might make sense to have an administrator
> > or some other senior engineer vet the project names
> > first.
>
> Yeah, a nice way to submit project creation for review would
> be cool! :) Any thoughts on how Gerrit could do that?

It would make sense not only for project creation requests but
also other types of requests, like branch creations. Completely
reusing the existing code review framework might be difficult
(unless we create artificial commits to express these types of
requests -- which actually might be a viable option), but having
a single "request for action review" system should be possible.

--
Magnus Bäck
ba...@google.com

[Magnus Bäck]

On Friday, April 27, 2012 at 12:08 EDT,

Martin Fick <mf...@codeaurora.org> wrote:

> For that matter, I think I recall someone requesting a way
> to review branch creation also. Perhaps what we need is
> some sort of pseudo changes. We could have a CREATE_PROJECT
> pseudo change and a CREATE_BRANCH pseudo change, perhaps a
> DELETE_BRANCH also?

Ah, yes. Even for organizations that are liberal with branch
creations, non fast-forward ref updates might be limited to
a very small number of people. Right now they're getting the
requests via email or some outside ticket system.

(I'm getting a tingling sense of featuritis here. But it would
be cool stuff, and certainly useful for several companies using
Gerrit.)

--
Magnus Bäck
ba...@google.com

[Nasser Grainawi]

Yeah, it does start to encroach on the "Gerrit as an issue tracker" idea that Shawn originally pushed away from. At the same time, Gerrit is awesome for reviewing git operations and seems we should try to leverage that...

>
> --
> Magnus Bäck
> ba...@google.com

>
> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en

--
Employee of Qualcomm Innovation Center, Inc.

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum

[Shawn Pearce]

On Fri, Apr 27, 2012 at 09:49, Nasser Grainawi <nas...@codeaurora.org> wrote:
> On Apr 27, 2012, at 10:22 AM, Magnus Bäck wrote:
>
>> On Friday, April 27, 2012 at 12:08 EDT,
>>     Martin Fick <mf...@codeaurora.org> wrote:
>>
>>> For that matter, I think I recall someone requesting a way
>>> to review branch creation also.  Perhaps what we need is
>>> some sort of pseudo changes.  We could have a CREATE_PROJECT
>>> pseudo change and a CREATE_BRANCH pseudo change, perhaps a
>>> DELETE_BRANCH also?
>>
>> Ah, yes. Even for organizations that are liberal with branch
>> creations, non fast-forward ref updates might be limited to
>> a very small number of people. Right now they're getting the
>> requests via email or some outside ticket system.
>>
>> (I'm getting a tingling sense of featuritis here. But it would
>> be cool stuff, and certainly useful for several companies using
>> Gerrit.)
>
> Yeah, it does start to encroach on the "Gerrit as an issue tracker" idea that Shawn originally pushed away from. At the same time, Gerrit is awesome for reviewing git operations and seems we should try to leverage that...

I am OK with Gerrit reviewing Git operations like project creation,
branch/tag creation/deletion, or non-fast-forward updates to
branch/tag.

I am NOT OK with Gerrit becoming a general purpose issue tracker. I
don't want too much feature creep in the product. We have a hard
enough time as it is just dealing with the features we do support, or
are trying to support, that general purpose issue tracking would
probably kill us.

[Martin Fick]

On Friday, April 27, 2012 10:49:22 am Nasser Grainawi wrote:
> On Apr 27, 2012, at 10:22 AM, Magnus Bäck wrote:
> > On Friday, April 27, 2012 at 12:08 EDT,
> >
> > Martin Fick <mf...@codeaurora.org> wrote:
> >> For that matter, I think I recall someone requesting a
> >> way to review branch creation also. Perhaps what we
> >> need is some sort of pseudo changes. We could have a
> >> CREATE_PROJECT pseudo change and a CREATE_BRANCH
> >> pseudo change, perhaps a DELETE_BRANCH also?
> >
> > Ah, yes. Even for organizations that are liberal with
> > branch creations, non fast-forward ref updates might
> > be limited to a very small number of people. Right now
> > they're getting the requests via email or some outside
> > ticket system.
> >
> > (I'm getting a tingling sense of featuritis here. But
> > it would be cool stuff, and certainly useful for
> > several companies using Gerrit.)
>
> Yeah, it does start to encroach on the "Gerrit as an
> issue tracker" idea that Shawn originally pushed away
> from.

Agreed, but the key advantage is that the review can be
encoded in Gerrit in a way which is actionable. With any
other ticketing system there will always need to be some
translation layer to then get it implemented in Gerrit.
This means everyone is doing it differently, and it is
likely to break in the future if Gerrit changes. And quite
simply that is more work: how do you know to really close a
ticket, how can you verify that it was implemented as
requested? With this in Gerrit, you would get a lot for
free that simply is not possible in a reliable way with any
other system,

-Martin

--
Employee of Qualcomm Innovation Center, Inc. which is a

[Magnus Bäck]

On Friday, April 27, 2012 at 12:49 EDT,

Nasser Grainawi <nas...@codeaurora.org> wrote:

> On Apr 27, 2012, at 10:22 AM, Magnus Bäck wrote:

[...]

> > (I'm getting a tingling sense of featuritis here. But it would
> > be cool stuff, and certainly useful for several companies using
> > Gerrit.)
>
> Yeah, it does start to encroach on the "Gerrit as an issue tracker"
> idea that Shawn originally pushed away from. At the same time, Gerrit
> is awesome for reviewing git operations and seems we should try to
> leverage that...

As long as we don't need the customizable state machine found in issue
trackers I think it's possible to get good leverage without going over
the top. Reviewing privileged Git operations should be a simple review
resulting in a score and a custom action being invoked when the change
is submitted.

--
Magnus Bäck
ba...@google.com

[Martin Fick]

On Friday, April 27, 2012 10:12:32 am Edwin Kempin wrote:
> +1 for being able to request, review and approve the
> creation/deletion of projects, branches, groups etc.

Hmm, thought from IRC discussion, perhaps another pseudo
change type would be a FF merge? Was it JBQ complaining
that this did not exist?

[Magnus Bäck]

On Friday, April 27, 2012 at 13:47 EDT,

Martin Fick <mf...@codeaurora.org> wrote:

> On Friday, April 27, 2012 10:12:32 am Edwin Kempin wrote:
> > +1 for being able to request, review and approve the
> > creation/deletion of projects, branches, groups etc.
>
> Hmm, thought from IRC discussion, perhaps another pseudo change type
> would be a FF merge? Was it JBQ complaining that this did not exist?

+1

Not sure about JBQ, but I'm pretty sure Ulrik has brought it up at some
point. I know I discussed it with him several times at my last job.

Perhaps it would be cleaner to make it possible to set permissions
that allow fast-forwards that don't introduce new commits.

--
Magnus Bäck
ba...@google.com

[Matthias Sohn]

2012/4/27 Magnus Bäck <ba...@google.com>

this would be also a nice enhancement for the Gerrit connector

of the Eclipse Skalli project portal [1] which already provides a 

self-service for Gerrit project creation.

[1] http://wiki.eclipse.org/Skalli/User_Guide#Gerrit_Connector 

--
Matthias

[Martin Fick]

While that may be a fine permission to have, I don't see it
solving the same problem. One use case for the pseudo FF
merge change is to review changes coming in from another
branch (like a merge), and I really think that review is
likely desired in that case, especially if you can review a
merge against its base,

[Magnus Bäck]

On Friday, April 27, 2012 at 15:47 EDT,

Martin Fick <mf...@codeaurora.org> wrote:

> On Friday, April 27, 2012 11:51:56 am Magnus Bäck wrote:

[...]

> > Perhaps it would be cleaner to make it possible to set permissions
> > that allow fast-forwards that don't introduce new commits.
>
> While that may be a fine permission to have, I don't see it solving
> the same problem. One use case for the pseudo FF merge change is to
> review changes coming in from another branch (like a merge), and I
> really think that review is likely desired in that case, especially
> if you can review a merge against its base,

Yes, you're right. While the features certainly are related they are
probably sufficiently orthogonal.

--
Magnus Bäck
ba...@google.com

[Pursehouse, David]

> +1 for being able to request, review and approve the creation/deletion of projects, branches, groups etc.
>

+1 here too. This functionality would be very useful.

Has it been discussed any further since this mail thread?

--
David Pursehouse
Configuration Manager
Sony Mobile Communications Japan, Inc.

[Shawn Pearce]

On Thu, May 24, 2012 at 2:39 AM, Pursehouse, David
<David.Pu...@sonymobile.com> wrote:
>> +1 for being able to request, review and approve the creation/deletion of projects, branches, groups etc.
>>
>
> +1 here too.  This functionality would be very useful.
>
> Has it been discussed any further since this mail thread?

No. It did not come up at the hackathon. We were pretty focused on the
plugin thing most of the week.

[Pursehouse, David]

>>> +1 for being able to request, review and approve the creation/deletion of projects, branches, groups etc.
>>>
>>
>> +1 here too.  This functionality would be very useful.
>>
>> Has it been discussed any further since this mail thread?
>
> No. It did not come up at the hackathon. We were pretty focused on the
> plugin thing most of the week.

I've added this as a new feature request [1].

Is this something that would be accepted as a new feature? If so, is anyone already working on it?

[1] http://code.google.com/p/gerrit/issues/detail?id=1433