Sorry, I've replied to Sumana directly instead of the mailing list. So now duplicating into the mailing list.
Sumana Harihareswara писал 2012-12-19 22:30:
Try these tips: https://www.mediawiki.org/wiki/Git/Code_review/Getting_reviews
Sumana, it's all very good but: 1) I think it's not so comfortable to push other developers personally when adding them as the reviewers... And I don't know whom to add as the reviewer, so I just choose randomly. But what if that guy doesn't want to do review for that extension? For example what if he is already very busy in working on mediawiki _core_, and I ask him to review a trivial extension? 2) Who can verify changes in extensions? There is no CI. So, people who can verify changes and people who can put +2 - are they the same people? But it again leads to short-circuiting all the work to the "core" people, and aren't they already busy? (I assume they are as they don't review all the changes) 3) As a solution, I think it would be good if - at least in not-so-important-as-the-core extensions - the changes merged automatically after getting, for example, 2x "+1"... Or will you end up with changes reviewed by not merged by anyone? And also, maybe it would also be good if the system automatically added some reviewers - randomly or based on some "ownership" rules...
- As a solution, I think it would be good if - at least in
not-so-important-as-the-core extensions - the changes merged automatically after getting, for example, 2x "+1"... Or will you end up with changes reviewed by not merged by anyone? And also, maybe it would also be good if the system automatically added some reviewers - randomly or based on some "ownership" rules...
This is a bad idea. It defies the concept of what +1 and +2 mean. Also, +1 permissions are given to literally everybody, so any two developers could override the opinion of the repository maintainer.
What we should do is get a list going on mediawiki.org with people listing what they're open to reviewing and how free they are to do so.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Sat, Dec 22, 2012 at 2:51 PM, vitalif@yourcmc.ru wrote:
Sorry, I've replied to Sumana directly instead of the mailing list. So now duplicating into the mailing list.
Sumana Harihareswara писал 2012-12-19 22:30:
Try these tips:
https://www.mediawiki.org/**wiki/Git/Code_review/Getting_**reviewshttps://www.mediawiki.org/wiki/Git/Code_review/Getting_reviews
Sumana, it's all very good but:
- I think it's not so comfortable to push other developers personally
when adding them as the reviewers... And I don't know whom to add as the reviewer, so I just choose randomly. But what if that guy doesn't want to do review for that extension? For example what if he is already very busy in working on mediawiki _core_, and I ask him to review a trivial extension? 2) Who can verify changes in extensions? There is no CI. So, people who can verify changes and people who can put +2 - are they the same people? But it again leads to short-circuiting all the work to the "core" people, and aren't they already busy? (I assume they are as they don't review all the changes) 3) As a solution, I think it would be good if - at least in not-so-important-as-the-core extensions - the changes merged automatically after getting, for example, 2x "+1"... Or will you end up with changes reviewed by not merged by anyone? And also, maybe it would also be good if the system automatically added some reviewers - randomly or based on some "ownership" rules...
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sun, 23 Dec 2012 08:35:44 -0800, Tyler Romeo tylerromeo@gmail.com wrote:
- As a solution, I think it would be good if - at least in
not-so-important-as-the-core extensions - the changes merged automatically after getting, for example, 2x "+1"... Or will you end up with changes reviewed by not merged by anyone? And also, maybe it would also be good if the system automatically added some reviewers - randomly or based on some "ownership" rules...
This is a bad idea. It defies the concept of what +1 and +2 mean. Also, +1 permissions are given to literally everybody, so any two developers could override the opinion of the repository maintainer.
What we should do is get a list going on mediawiki.org with people listing what they're open to reviewing and how free they are to do so.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
Actually registration is open to everyone now by simple form submission. So actually, any one developer could get any change they wanted merged. All they need to do is trivially register a second labs account.
Actually registration is open to everyone now by simple form submission. So actually, any one developer could get any change they wanted merged. All they need to do is trivially register a second labs account.
Okay, but current situation is also a problem, because with it reviewing and merging takes much more time. And as I've said, I think most extensions aren't as important as the core, and limitting approve for them to core developers is just a waste...
Maybe you should add some group similar to previous (SVN) "commit access to extensions", so a wider group of people could merge changes to the extensions?
On Wed, Dec 26, 2012 at 7:09 PM, vitalif@yourcmc.ru wrote:
Actually registration is open to everyone now by simple form submission. So actually, any one developer could get any change they wanted merged. All they need to do is trivially register a second labs account.
Okay, but current situation is also a problem, because with it reviewing and merging takes much more time. And as I've said, I think most extensions aren't as important as the core, and limitting approve for them to core developers is just a waste...
Maybe you should add some group similar to previous (SVN) "commit access to extensions", so a wider group of people could merge changes to the extensions?
This would have to be limited to extension with authors/maintainers opting in for your system.
I'm not feel comfortable to enforce this practice on any extension.
This situation could vary from one set of extensions to another. For example, changes on the semantic ones are very quickly reviewed.
Agreed. I know that for my extensions, while I'm open to taking in co-maintainers who want to approve commits, I'd definitely not be comfortable just opening it to the public.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Wed, Dec 26, 2012 at 1:53 PM, Sébastien Santoro <dereckson@espace-win.org
wrote:
On Wed, Dec 26, 2012 at 7:09 PM, vitalif@yourcmc.ru wrote:
Actually registration is open to everyone now by simple form submission. So actually, any one developer could get any change they wanted merged. All they need to do is trivially register a second labs account.
Okay, but current situation is also a problem, because with it reviewing
and
merging takes much more time. And as I've said, I think most extensions aren't as important as the
core,
and limitting approve for them to core developers is just a waste...
Maybe you should add some group similar to previous (SVN) "commit access
to
extensions", so a wider group of people could merge changes to the extensions?
This would have to be limited to extension with authors/maintainers opting in for your system.
I'm not feel comfortable to enforce this practice on any extension.
This situation could vary from one set of extensions to another. For example, changes on the semantic ones are very quickly reviewed.
-- Best Regards, Sébastien Santoro aka Dereckson http://www.dereckson.be/
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 12/26/2012 01:09 PM, vitalif@yourcmc.ru wrote:
Actually registration is open to everyone now by simple form submission. So actually, any one developer could get any change they wanted merged. All they need to do is trivially register a second labs account.
Okay, but current situation is also a problem, because with it reviewing and merging takes much more time. And as I've said, I think most extensions aren't as important as the core, and limitting approve for them to core developers is just a waste...
Maybe you should add some group similar to previous (SVN) "commit access to extensions", so a wider group of people could merge changes to the extensions?
When I look at https://www.mediawiki.org/wiki/Git/Gerrit_project_ownership and its history, I see that it's reasonably easy to get Gerrit ownership for less-used and less-maintained extensions, especially ones that are not deployed on Wikimedia sites. But perhaps we should be even more open to newer contributors. Maybe our rule should be: if an extension is not deployed on Wikimedia sites, then we should basically allow anyone to merge new code in (disallowing self-merges), unless the existing maintainers object. This would make things more flexible and encourage faster development in the extensions community, and help developers get more practice in code review so that they could also apply for maintainership of other extensions and core.
What do people think?
On Wed, Feb 13, 2013 at 4:35 PM, Sumana Harihareswara sumanah@wikimedia.org wrote:
Maybe our rule should be: if an extension is not deployed on Wikimedia sites, then we should basically allow anyone to merge new code in (disallowing self-merges), unless the existing maintainers object.
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.
-Chad
On 02/13/2013 07:57 PM, Chad wrote:
On Wed, Feb 13, 2013 at 4:35 PM, Sumana Harihareswara sumanah@wikimedia.org wrote:
Maybe our rule should be: if an extension is not deployed on Wikimedia sites, then we should basically allow anyone to merge new code in (disallowing self-merges), unless the existing maintainers object.
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?
You still have to ask for each extension you want, but if the maintainer's okay with it (or not around), the burden of proof is less.
No one really needs review rights on *all* the non-deployed extensions, only the few they work on.
Matt Flaschen
On Wed, Feb 13, 2013 at 8:12 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
How about instead of "can review all extensions", we make it easier to request review rights on non-WMF extensions?
You still have to ask for each extension you want, but if the maintainer's okay with it (or not around), the burden of proof is less.
No one really needs review rights on *all* the non-deployed extensions, only the few they work on.
I tend to agree. And I think this is pretty much the standard we have ("consensus by existing devs"). For anything that's not maintained by anyone, I think we can just AGF.
-Chad
On 02/14/2013 02:12 AM, Matthew Flaschen wrote:
On 02/13/2013 07:57 PM, Chad wrote:
On Wed, Feb 13, 2013 at 4:35 PM, Sumana Harihareswara sumanah@wikimedia.org wrote:
Maybe our rule should be: if an extension is not deployed on Wikimedia sites, then we should basically allow anyone to merge new code in (disallowing self-merges), unless the existing maintainers object.
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.
You still have to ask for each extension you want, but if the maintainer's okay with it (or not around), the burden of proof is less.
No one really needs review rights on *all* the non-deployed extensions, only the few they work on.
Matt Flaschen
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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."
-Chad
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.
Cheers,
Marco
On Wed, Feb 13, 2013 at 9:33 PM, Marco Fleckinger marco.fleckinger@wikipedia.at 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.
Having these groups in Gerrit, or just in practice for application for permissions? Having groups like this in Gerrit would be a pain, that's what I'm saying.
-Chad
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
On 02/14/2013 12:04 AM, Dmitriy Sintsov wrote:
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'm wary about giving such classifications too much weight given that they're inherently subjective.
Remember how many completely private wikis there are, which don't disclose which extensions they run.
Matt Flaschen
Also, the locations of extensions should be stable. If the repos start moving around as extensions move up and down the ladder it will cause confusion.
-bawolff On 2013-02-14 1:12 AM, "Matthew Flaschen" mflaschen@wikimedia.org wrote:
On 02/14/2013 12:04 AM, Dmitriy Sintsov wrote:
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'm wary about giving such classifications too much weight given that they're inherently subjective.
Remember how many completely private wikis there are, which don't disclose which extensions they run.
Matt Flaschen
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 14.02.2013 9:14, Brian Wolff wrote:
Also, the locations of extensions should be stable. If the repos start moving around as extensions move up and down the ladder it will cause confusion.
Disadvantages are really small comparing to huge advantages for both reviewers and extension's authors. Another advantage is that importance and stability of extension will be evaluated by experienced WMF developer rather than self-placing extension description page into [[Category:Stable extensions]]. Dmitriy
I would consider git pull to mysteriously stop working because somebody moved the git repo to be a pretty big disadvantage.
-bawolff On 2013-02-14 1:22 AM, "Dmitriy Sintsov" questpc@rambler.ru wrote:
On 14.02.2013 9:14, Brian Wolff wrote:
Also, the locations of extensions should be stable. If the repos start moving around as extensions move up and down the ladder it will cause confusion.
Disadvantages are really small comparing to huge advantages for both
reviewers and extension's authors. Another advantage is that importance and stability of extension will be evaluated by experienced WMF developer rather than self-placing extension description page into [[Category:Stable extensions]]. Dmitriy
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 02/14/2013 12:25 AM, Brian Wolff wrote:
I would consider git pull to mysteriously stop working because somebody moved the git repo to be a pretty big disadvantage.
Similar to what I said earlier, I don't think anyone needs to request review/merge rights for all "non-WMF less important" extensions (or another grouping like that). They can request rights for extensions they're actually working on.
We should just socially consider who's using the extension (that we know of), how important it is (subjective), and whether it's being actively maintained (generally pretty clear) when granting these rights.
I don't think we need formal groups beyond whether the WMF is using it (which is already marked clearly).
Matt Flaschen
On 23 December 2012 17:35, Tyler Romeo tylerromeo@gmail.com wrote:
This is a bad idea. It defies the concept of what +1 and +2 mean. Also, +1 permissions are given to literally everybody, so any two developers could override the opinion of the repository maintainer.
I'd phrase that the other way around: the way +1 and +2 are used now defies the concept of what +1 and +2 actually mean: they are numbers, so twice +1 should be the same as +2 (after all, 1+1=2). The concept are 'looks good to me' and 'approved' (and 'no opinion' and 'do not submit'), and I would suggest to name them something else than +1 and +2 (as well was 0 and -1 -- those also imply you can just add up the opinions). Simply using 'Approved', 'OK', 'Comment' and 'Problem' is simple enough, I'd think.
Merlijn
That's the way Gerrit was designed. Quoting from the Gerrit documentation:
The label that the reviewer selects determines what can happen next. The +1 and -1 level are just an opinion where as the +2 and -2 levels are allowing or blocking the change. In order for a change to be accepted it must have at least one +2 and no -2 votes. Although these are numeric values, they in no way accumulate; two +1s do not equate to a +2.
The idea behind it is that developers can +1 or -1 to express their opinion, but only a -2 or +2 will actually take effect. In many code repositories, code is only ever submitted when the maintainer approves it, thus only the maintainer can actually approve or deny a change. However, since open source development involves many users, the +1/-1 functionality allows others to get their opinion in.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Sun, Dec 23, 2012 at 12:29 PM, Merlijn van Deen valhallasw@arctus.nlwrote:
On 23 December 2012 17:35, Tyler Romeo tylerromeo@gmail.com wrote:
This is a bad idea. It defies the concept of what +1 and +2 mean. Also,
+1
permissions are given to literally everybody, so any two developers could override the opinion of the repository maintainer.
I'd phrase that the other way around: the way +1 and +2 are used now defies the concept of what +1 and +2 actually mean: they are numbers, so twice +1 should be the same as +2 (after all, 1+1=2). The concept are 'looks good to me' and 'approved' (and 'no opinion' and 'do not submit'), and I would suggest to name them something else than +1 and +2 (as well was 0 and -1 -- those also imply you can just add up the opinions). Simply using 'Approved', 'OK', 'Comment' and 'Problem' is simple enough, I'd think.
Merlijn
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org