On 2019-04-09 07:43, Isarra Yos wrote:

On 09/04/2019 05:17, Isarra Yos wrote:

...

This seems to be broken, or something. It's causing problems for collaboration. Please fix.

I now hear that this is intentional for spam/vandalism reasons. This seems unwise. Regardless, where is the documentation about this? What is the recommended method to now collaborate on specific patches?

Hopefully this will not stay disabled forever, for I also miss the feature.

In the meantime, you can use the traditional Git way of generating patch files and sending them by email (or perhaps, in a modern twist, via Phabricator).

To generate a patch file of the most recent commit:

git format-patch -1

(that's 'dash one', and it's critical, because otherwise Git will generate patch files for ALL commits)

Then upload the generated file to Phabricator or something.

To apply such a patch file and turn it into a commit:

git am foo.patch

There are some other options for dealing with multiple dependent commits, if you ever need them.

On 09/04/2019 09:21, Bartosz Dziewoński wrote:

Hopefully this will not stay disabled forever, for I also miss the feature.

In the meantime, you can use the traditional Git way of generating patch files and sending them by email (or perhaps, in a modern twist, via Phabricator).

To generate a patch file of the most recent commit:

git format-patch -1

(that's 'dash one', and it's critical, because otherwise Git will generate patch files for ALL commits)

Then upload the generated file to Phabricator or something.

To apply such a patch file and turn it into a commit:

git am foo.patch

There are some other options for dealing with multiple dependent commits, if you ever need them.

The problem is I'm going to need to do that for like one in every five commits, and often for multiple patches in a set. And... yes, we /do/ wind up with multiple dependent commits at times.

To explain why this comes up so much for me: I am a UX designer. I'm not much of a dev. Most of what I do is describe generally what I want and then throw it at someone else, and they implement the actual logic, but then they pass it back to me to fill in the rest of the interaction stuff, because not only would it be incredibly tedious for me to try to explain every possible combination users might run into, it probably wouldn't even work. Without the code in front of me, without testing it and playing through each use case to ensure it actually results in the expected behaviour, I am going to miss things.

While it does work in some cases to simply have the logic in one patch and the interaction in another, much of what we work on is considered stable, where we should not be merging half-complete patches unless we absolutely must.

(Note too that this is specifically /my/ use case - this isn't even getting into issues with minor changes that are easier to apply than to explain, especially when helping newcomers through where it'd be needlessly frustrating for them to implement a bunch of minor fixes when the core of their patch is in fact good; or when just dealing with typos; or when restoring someone's five-year-old abandoned patch because wait, we actually do need that now; or...)

Should we just, uh, not be using gerrit, or something? Because that's just... complicated.

-I

On 09/04/2019 17:38, Isarra Yos wrote:

On 09/04/2019 16:44, Tyler Cipriani wrote:

...

On 19-04-09 05:17:17, Isarra Yos wrote:

...

This seems to be broken, or something. It's causing problems for collaboration. Please fix.

This is the addPatchSet permission in Gerrit.

That particular permission was recently abused, and at that time the permission was modified. The current status will remain for at least the next week or two while we sort out some other Gerrit problems.

The current status is that "Project Owners" can use addPatchSet for any projects they own: this does not necessarily map to +2/-2 permissions for a given project, but should mostly align.

For any projects in the "mediawiki" hierarchy, the "mediawiki" group has the ability to addPatchSet.

After our current problems are resolved, I'd like to talk both with the folks impacted and with the security team about finding some middle ground between the current status and anyone being able to modify any patchset at any time.

Hi. I'm trying to think of a way to put this politely, but I can't, so: this is insane.

Please reconsider, or I will likely simply need to put off a lot of my work entirely until it is resolved, which is particularly problematic as this was the week when I was supposed to properly resume my grant work in particular. I do not have ownership on many of the repositories that I need to work on, despite those also being among the ones most likely to require the sort of back and forth amending that this blocks, so this is about as bad for me as having gerrit down entirely, as that is pretty much where having to fall back to emailing patches puts us. (And when that happened I just threw my arms in the air and went to the beach.)

To clarify, I get what you're trying to do, but there has got to be a better solution besides denying key features to and thus impairing long-term contributors, because disabling this for everyone (but apparently WMDE (?!)) does exactly that. On the wikis, for instance, we have specific groups for this sort of thing (rollback, file moving, bypass captcha, bypass rate limits), to let established users do the things they need to do, without it being allowed of absolutely everyone from the start, and without requiring them to be admins, either, to do it. Perhaps actually using one of our more general existing groups for this here would make sense?

-I

On 09/04/2019 19:40, Tyler Cipriani wrote:

Hello,

On 19-04-09 17:50:12, Isarra Yos wrote:

...

To clarify, I get what you're trying to do, but there has got to be a better solution besides denying key features to and thus impairing long-term contributors, because disabling this for everyone (but apparently WMDE (?!)) does exactly that. On the wikis, for instance, we have specific groups for this sort of thing (rollback, file moving, bypass captcha, bypass rate limits), to let established users do the things they need to do, without it being allowed of absolutely everyone from the start, and without requiring them to be admins, either, to do it. Perhaps actually using one of our more general existing groups for this here would make sense?

Bawolff has suggested Trusted-Contributors as a group that might make sense to add. That seems sane to me, so I've added that group in addition to the list above. Hopefully that unblocks your work.

I agree: having specific groups that are granted specific permissions that allow established users to continue their work unobstructed should be achievable in the near-term.

Thank you. And apparently I was only even added to that group just last night in the hopes that it would get around this, so... now that it does, great! (For anyone else who needs to be added to this for now, who should they be reaching out to?)

Sorry about reacting so unkindly - it was just particularly frustrating when it seemed like I was being ignored here, but other groups were being resolved (though as I understand it now, apparently specific members with access simply added that themselves, go figure).

-I

On 09/04/2019 17:53, Greg Grossmeier wrote:

PS: I just saw your follow-up reply. Sadly Gerrit is not mediawiki ;) so it doesn't have all of the other built in anti-abuse features that comes with the nice user features.

Most of MediaWiki's anti-abuse features consist of only applying certain rights to certain groups. This is, likewise, a certain right. Gerrit, likewise, has groups. This right can be attached to groups, as evidenced by the fact that it has already been attached to certain groups.

Given that we have no other feasible ways to do the thing the right allows, all I am asking is that this right be added to something that known volunteers and other trusted contributors can be added to. I believe there is even a group called 'trusted-contributors' already.

-I