Page MenuHomePhabricator

Create trusted group in gerrit
Closed, DeclinedPublic

Description

This group would be similar to phabricator's one.

IE, it will allow users to edit assignees of other users changes. Would allow them to delete there own changes if they were uploaded by mistake (allows us to reduce our reindex time if we delete spammy changes).

This would also be used in the future to allow users to make there changes private or not and to allow users to edit the hashtag feature.

This could be expanded to allow rebasing other users changes too.

This could also be expanded to allow users to do other things.

Related Objects

Event Timeline

Peachey88 subscribed.

IE, it will allow users to edit assignees of other users changes.

I thought Chad wanted to disable this feature all together?

This would also be used in the future to allow users to make there changes private

Do we really want private changes in gerrit?

or not and to allow users to edit the hashtag feature.

Would hashtags be useful in our current ecosystem or should we leave them off? We haven't had them since CR days.

@Peachey88 gerrit 2.15 replaces drafts with privates. And yes it could be used for creating security changes.

Drafts has been split into mutiple features, private changes and Work in Progress.

Hashatags is a notedb feature so when we move to gerrit 2.15 we will be migrating to notedb (stores most of the data in the db, gerrit is discontinuing support for the db in 3.1 but requires notedb in 3.0)

hashtags also allows you to tag your change with mutiple tags which you carn't do with topic. I think that will fix T37534 .

I agree with private patches for security updates. Pasting things in Phabricator private tasks are a bit of a pain. When ready to merge, we can make those public again.

With regards to assignees, I don't really understand what this is for. We can stick with the 'reviewers' field as usual.

In general I'm positive to this new proposed group.

@MarcoAurelio the assignee field is for picking a reviewer who will review the code.

IE for example you have

Example1, example2 and exampl3 as reviewers, you add example1 to the assignee field. They then review the code.

Do we really want private changes in gerrit?

So far the position has always been that we don't trust gerrit enough for that and eh,, see this https://bugs.chromium.org/p/gerrit/issues/detail?id=8111

Especially with the things I've heard about it, enabling private changes
would be a bad idea, regardless of whether they can be used for security
patches or not

@Krenair there's no option to disable private changes in 2.15, there is in 2.16 / 3.0

But we can block it for all users right?

Yea we should disable that feature or people will start using it.

Apparently upstream added the feature into the stable release but decided to _not_ add the option to turn it off, which is sitting here on another branch

https://gerrit-review.googlesource.com/c/gerrit/+/148652/

(paladox showed me)

demon closed this task as Declined.EditedFeb 5 2018, 9:24 PM

IE, it will allow users to edit assignees of other users changes.

I don't see a reason for anyone to edit other people's changes' assignee.

Would allow them to delete there own changes if they were uploaded by mistake (allows us to reduce our reindex time if we delete spammy changes).

I don't like deleting changes, it confuses people. But if we do allow it, all users should be able to do it. Also, the # of changes we'd delete wouldn't be enough to reduce indexing time noticeably.

This would also be used in the future to allow users to make there changes private or not and to allow users to edit the hashtag feature.

Private changes suck and we're going to disable them

This could be expanded to allow rebasing other users changes too.

This is the one nice thing...I hate that freaking rebase button. I've been inclined to disable it outright.

This could also be expanded to allow users to do other things.

A group with an undefined future purpose just increases maintenance burden.

Sooooooo, I'm declining this. I don't see a huge motivation for making such a group, all the proposed reasons are stuff we should do for everyone or no one. The only justification would be the rebase thing, but I'd much rather have a way to disable it for the few problematic users than enable it for a select few.