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(a)gmail.com> wrote:
On Wed, Dec 11, 2013 at 12:00 PM, Brad Jorsch (Anomie)
<
bjorsch(a)wikimedia.org> wrote:
On Wed, Dec 11, 2013 at 2:54 PM, Matthew Walker
<mwalker(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l