"I'm totally cool with the idea of code review for Gadgets & so forth, just not using Gerrit. We considered it for Scribunto (and heck, I wrote half of a proof of concept) but shot it down because the idea totally sucked."
Chad, can you expand on that statement. I've been toying for some time with writing something that allows documentation to be synced both ways. E.g. for hooks and variables and what not. My simplistic toy example had a 1:1 link but I've been trying to figure out how to make it more complex. (Ideally this would also allow documentation to be linked to a branch and thus we then have versioned documentation)
~Matt Walker Wikimedia Foundation Fundraising Technology Team
On Wed, Dec 11, 2013 at 11:21 AM, Chad innocentkiller@gmail.com wrote:
On Wed, Dec 11, 2013 at 11:04 AM, Jon Robson jdlrobson@gmail.com wrote:
Many a time I've talked about this I've hit the argument that gerrit is confusing to some users and is a barrier for development, but this is a terrible unacceptable attitude to have in my opinion. Our end users
deserve
a certain standard of code. I'm aware using a code review process can
slow
things down but I feel this is really essential. I for one greatly
benefit
from having every single piece of my code scrutinized and perfected
before
being consumed by a wider audience. If this is seen as a barrier, someone should investigate making it possible to send wiki edits to Gerrit to simplify that process.
Sending wiki edits to Gerrit for review? Absolutely not.
I'm totally cool with the idea of code review for Gadgets & so forth, just not using Gerrit. We considered it for Scribunto (and heck, I wrote half of a proof of concept) but shot it down because the idea totally sucked.
-Chad _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Dec 11, 2013 at 2:54 PM, Matthew Walker mwalker@wikimedia.org wrote:
"I'm totally cool with the idea of code review for Gadgets & so forth, just not using Gerrit. We considered it for Scribunto (and heck, I wrote half of a proof of concept) but shot it down because the idea totally sucked."
Chad, can you expand on that statement.
I'm not Chad, but one of the big issues is this: Consider the trouble that some of us as developers have using Git and Gerrit. Now think about trying to get non-developer JS and CSS coders to be able to use Git and Gerrit, much less to *want* to use Git and Gerrit rather than torches and pitchforks.
On Wed, Dec 11, 2013 at 12:00 PM, Brad Jorsch (Anomie) < bjorsch@wikimedia.org> wrote:
On Wed, Dec 11, 2013 at 2:54 PM, Matthew Walker mwalker@wikimedia.org wrote:
"I'm totally cool with the idea of code review for Gadgets & so forth,
just
not using Gerrit. We considered it for Scribunto (and heck, I wrote half
of
a proof of concept) but shot it down because the idea totally sucked."
Chad, can you expand on that statement.
I'm not Chad, but one of the big issues is this: Consider the trouble that some of us as developers have using Git and Gerrit. Now think about trying to get non-developer JS and CSS coders to be able to use Git and Gerrit, much less to *want* to use Git and Gerrit rather than torches and pitchforks.
That's a big part of it.
The other part is that Gadgets and site CSS/JS stuff has always been a system that empowers wikis to make their own changes quickly. Gerrit may produce better reviewed code, but it's certainly not a rapid process.
-Chad
Ah; so it's actually slightly different use cases then.
My thought is that it's on the developers to merge changes that come from the wiki.
I've thought of two ways this could work:
* For every new merge touching a documentation file; we reject changes via a jenkins job when there are still outstanding changes on the wiki (aka, we allow only fast forward merges for that source file).
* Or have a script in jenkins that would automatically merge changes from the source branch into the wiki page (causing a failure if there was a merge conflict.) That way the wiki version remains as it is with new changes from source being automatically applied -- and selectively we accept changes into the source version.
~Matt Walker Wikimedia Foundation Fundraising Technology Team
On Wed, Dec 11, 2013 at 12:04 PM, Chad innocentkiller@gmail.com wrote:
On Wed, Dec 11, 2013 at 12:00 PM, Brad Jorsch (Anomie) < bjorsch@wikimedia.org> wrote:
On Wed, Dec 11, 2013 at 2:54 PM, Matthew Walker mwalker@wikimedia.org wrote:
"I'm totally cool with the idea of code review for Gadgets & so forth,
just
not using Gerrit. We considered it for Scribunto (and heck, I wrote
half
of
a proof of concept) but shot it down because the idea totally sucked."
Chad, can you expand on that statement.
I'm not Chad, but one of the big issues is this: Consider the trouble that some of us as developers have using Git and Gerrit. Now think about trying to get non-developer JS and CSS coders to be able to use Git and Gerrit, much less to *want* to use Git and Gerrit rather than torches and pitchforks.
That's a big part of it.
The other part is that Gadgets and site CSS/JS stuff has always been a system that empowers wikis to make their own changes quickly. Gerrit may produce better reviewed code, but it's certainly not a rapid process.
-Chad _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hey,
Has there been thought on how GitHub can potentially help here? I'm not sure it fits the workflow well, though can make the following observations:
* People can click an "edit" button on GH to edit the code, much like on wiki. * If the GH web UI is used, people do not have to install git * They do not even need to understand git or know what it is * A workflow only involving code in actual source control can potentially be more streamlined and rely less on custom written solutions that also need to be maintained * Having such code in an "easy to use" (compared to git+gerrit) system that nevertheless provides a way to move to doing it more "professionally" might well have more people make the jump at some point
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 --
On Wed, Dec 11, 2013 at 3:21 PM, Jeroen De Dauw jeroendedauw@gmail.comwrote:
Hey,
Has there been thought on how GitHub can potentially help here? I'm not sure it fits the workflow well, though can make the following observations:
Unless you're implying that github writes some code for us, I'm going to assume this is a troll from you and leave it at that.
- Ryan
It's not a bad thought; but I don't think it'll work for a couple of reasons: * It causes people to leave the site * GItHub for various reasons requires an account (which most likely they wont have and it doesn't seem correct to require one given our editing philosophy) * The editing interface is completely different that of the MediaWiki interface * It would most likely complicate what's already going to be a fairly complicated merge / review process.
~Matt Walker Wikimedia Foundation Fundraising Technology Team
On Wed, Dec 11, 2013 at 12:21 PM, Jeroen De Dauw jeroendedauw@gmail.comwrote:
Hey,
Has there been thought on how GitHub can potentially help here? I'm not sure it fits the workflow well, though can make the following observations:
- People can click an "edit" button on GH to edit the code, much like on
wiki.
- If the GH web UI is used, people do not have to install git
- They do not even need to understand git or know what it is
- A workflow only involving code in actual source control can potentially
be more streamlined and rely less on custom written solutions that also need to be maintained
- Having such code in an "easy to use" (compared to git+gerrit) system that
nevertheless provides a way to move to doing it more "professionally" might well have more people make the jump at some point
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I'm not Chad, but one of the big issues is this: Consider the trouble that some of us as developers have using Git and Gerrit. Now think about trying to get non-developer JS and CSS coders to be able to use Git and Gerrit, much less to *want* to use Git and Gerrit rather than torches and pitchforks.
I'm confused.. non-developers writing JS and CSS? This scares the bejesus outta me.
Heh; wrong thread to discuss that in Jon -- this one is about non-developers helping out writing documentation for configuration variables and what not without having to modify the source file in gerrit.
The OTHER thread, which I forked from, is the one about what we already allow (users to modify common.js and common.css) and how to get that code reviewed.
~Matt Walker Wikimedia Foundation Fundraising Technology Team
On Wed, Dec 11, 2013 at 2:35 PM, Jon Robson jdlrobson@gmail.com wrote:
I'm not Chad, but one of the big issues is this: Consider the trouble that some of us as developers have using Git and Gerrit. Now think about trying to get non-developer JS and CSS coders to be able to use Git and Gerrit, much less to *want* to use Git and Gerrit rather than torches and pitchforks.
I'm confused.. non-developers writing JS and CSS? This scares the bejesus outta me.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, 11 Dec 2013 23:35:43 +0100, Jon Robson jdlrobson@gmail.com wrote:
I'm confused.. non-developers writing JS and CSS? This scares the bejesus outta me.
There's so many movements urging people to learn to code right now, I don't see how this is surprising anymore. Yes, physicians and economists can write JavaScript too, and if their JS isn't the ultimate prettiest code, but if it works for their purposes, then so what? That's a net gain.
And it's not very easy to cause a major security bug when writing code that runs client-side and usually only in response to user action. Most gadgets don't, say, parse untrusted input from *other* users.
On 2013-12-11 4:52 PM, Bartosz Dziewoński wrote:
On Wed, 11 Dec 2013 23:35:43 +0100, Jon Robson jdlrobson@gmail.com wrote:
And it's not very easy to cause a major security bug when writing code that runs client-side and usually only in response to user action. Most gadgets don't, say, parse untrusted input from *other* users.
That's not always true. There are a variety of scenarios where a Gadget author may do something relatively common and innocent, and through a bad practice mistake could inadvertently introduce a gaping XSS vector that could be used to attack any user for whom said gadget is merely enabled.
For example take a gadget which runs unconditionally on a specific URL, like how the AJAX recent changes does, triggering a special view when on `Special:BlankPage?blankspecial=ajaxrc`. Now say the gadget happens to take user input from the URL, for example a page title, because the gadget wants per-page stuff and include a link inside the toolbox on every page that would link to the tool passing along the title of the page (title might be the most common, but there are plenty of other reasons to accept user input from the URL). If the gadget author decided to output this title into the page, they might accidentally do it in a way that amounted to raw html concatenation: Such as `+ userInput +`ing it into a block of html, passing it to a mw.message in a parameter that accepts raw html, using innerHTML in the wrong way, using some other interface that actually accepts HTML, etc... If this happened, a glaring XSS vector would suddenly become open. Anyone, anywhere on the internet could simply include an iframe pointed to the URL and use that parameter to inject any html and script they wanted creating a full-blown XSS attack. (And thanks to user scripts, etc... escalating any momentary XSS attack into a persistent on-site XSS attack is trivial)
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
wikitech-l@lists.wikimedia.org