On 14.02.2013 6:33, Marco Fleckinger wrote:
On 02/14/2013 03:28 AM, Chad wrote:
On Wed, Feb 13, 2013 at 9:22 PM, Marco Fleckinger marco.fleckinger@wikipedia.at wrote:
Having a "can review all extensions" group is easy, but allowing for exemptions will be a pain to manage the ACLs for. For every extension that opts out of being reviewed by this group, we'd have to adjust its ACL to block the inherited permissions.
How about instead of "can review all extensions", we make it easier to request review rights on non-WMF extensions?
Good idea, but in general there could just be 3+ different classes of extensions? The class can be calculated by its importance, e.g. installed on WMF-sites, number of other wikis using it, etc.
Having classes of extensions is difficult to maintain from an ACL standpoint. Permissions in Gerrit are directly inherited (and there's no multiple inheritance), so things in mediawiki/extensions/* all have the same permissions. So having rules that apply to only some of those repositories requires editing ACLs for each repository in each "group."
Sorry, I think you misunderstood me. I meant classes like:
- "Used by WMF"
- "non-WMF very important"
- "non-WMF important"
- "non-WMF less important"
- "non-WMF unimportant"
No multiple inheritance will be needed for this model.
That is a really great idea. If there were mediawiki/extensions/(wmf|non-wmf-unimportant|non-wmf-important)/* subdirectories introduced, such classification should encourage extension developers to improve their extensions so they can move up from "non-WMF unimportant" to "non-WMF important"and maybe higher. I do not develop for MW last year, however this idea is great and I give my personal +100 for having extensions importance hierarchy in repository. Should be easier for reviewers as well. Maybe even corporate donations campaigns for "non-WMF very important" can be introduced at some late stage then, which is even better to make more extensions useful and stable. Dmitriy