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