Rob Lanphier robla@wikimedia.org wrote:
On Fri, Mar 23, 2012 at 10:13 AM, Chad innocentkiller@gmail.com wrote:
On Fri, Mar 23, 2012 at 1:11 PM, Rob Lanphier robla@wikimedia.org wrote:
On Fri, Mar 23, 2012 at 10:03 AM, Chad innocentkiller@gmail.com wrote:
I disagree here. The wmf branches should always be linear, and you should never merge to it without accepting that it may get scapped.
Actually, you should never merge to master without accepting that it may get scapped. Why have two layers here?
Well true, but I still don't see an instance where you'd merge to master but *not* be willing to have it deployed.
Chad and I discussed this, and I think we figure out where we were talking past each other. I'll let him explain in more detail when he gets a chance, but the short answer is we'll probably be doing something roughly like I described as the second plan in my original email, with the addition of liberal use of tagging. We could even *try* to get away with tagging instead of branching, and then only branch when necessary.
How "git committers" (i.e. mere mortals) will be able to propose changes to be deployed in wmf production (a.k.a. "1.19wmf1" tag in [[Special:Code]]?
If we plan to use gerrit for that (submitting commits for review in the "wmf" branches by the means of refs/for/wmf-something), I would ask for one thing - can we full go end-to-end and test the workflow with actual commands?
I have noticed potential issues with gerrit+git combination vs pure git workflow:
* It seems I can't have a longer running branch with my changes on some topic - those commits cannot be easily submitted to gerrit (since my branch will likely contain merges from master and we don't want't them to be resubmitted via the dependency tree)
* It seems necessary to change "Change-Id" everywhere for "git cherry-pick" to work without -n - it seems that cherry-pick does not invoke our commit-msg hook when committing. Neither does "git merge".
Those things limit possibilities in moving commits between branches (official or local ones), so I think it would be good to review the process in the test tree using some actual commands (and with some test users that don't have privilege to cross the gated trunk involved).
More on the second case in separate thread.
//Saper