Talk:Requests for comment/Branching

I think I'm actually interested in something similar to you are (or at least related). I personally would really like to look into a flagged-revs type extension that works a little more like how gerrit works - perhaps over the summer when I actually have free time. However, I do find some of this RFC confusing. "Enciclopedia Libre Universal en Español" doesn't seem particularly relavent - There have been thousands of wikipedia forks. While that one is important for historical reasons of being a very early fork, its far from the only fork and doesn't really have anything to do with branching. I personally don't see the connection between release tags and rev tagging. I'm also doubtful that your proposal would exactly kill view source. You don't cover all the use cases of things being protected. (Sometimes things are protected because we literally want nobody to edit them whatsoever). Bawolff (talk) 15:34, 1 January 2013 (UTC)
 * Thank you for the very helpful feedback. I think we're on the same page regarding rev tagging &mdash; would you explain how you envision making an extension which works like gerrit?  Currently, all changes exist in a single branch, and the review process determines which revision is tagged as the "release".  So, it would be more in line with our "gated trunk" source control policy if the master branch of an article contained only reviewed changes, and unreviewed changes had to be rebased to the master branch tip in order to be merged into "production".
 * You might be right about my "forking" tangent, I've expanded that section a bit to demonstrate that they accomplished this fork with virtually no automated tools at all (therefore, such a thing is even more feasible with better tools), but I should give more examples of what would become possible with a flexible history model. Adamw (talk) 20:17, 1 January 2013 (UTC)