<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 31, 2015 at 2:32 PM, Matthew Jordan <span dir="ltr"><<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey everyone:<br></blockquote><div><br></div><div>Hi!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Just as a brief status update on the Asterisk Git Migration project,<br>
here is where we stand today, and what the next steps are:<br></blockquote><div><br></div><div>Awesome work so far.  :-) </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There's a large amount of intervening work that has to be done, and<br>
some questions that still need to be answered. In no particular order:<br>
<br>
(1) In test runs of building the Asterisk repo, I've successfully<br>
managed to pull in the team repos that are still 'active'. Since<br>
Gerrit acts as the canonical Git repo, we can set it up so that direct<br>
pushes to team branches are allowed and don't require a code review -<br>
although code reviews can be done if someone desires it. For those who<br>
use team branches a lot, does this sound acceptable?<br></blockquote><div><br></div><div>What's the benefit of trying to keep team branches at all vs. just letting people use their own git trees hosted on one of the many personal git hosting options (github or whatever) ?</div><div><br></div><div>If it's about several people collaborating on a branch, that makes sense to me to do as a feature branch in gerrit, but it seems like the exception, not the rule.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(2) Today, we merge up the branches - 11 => 13, 13 => trunk, etc.<br>
After the move, it looks like the best way to handle the merge process<br>
is going to be to make patches against trunk, then cherry-pick them<br>
back to the currently maintained branches. For long time users of<br>
Gerrit, does this seem appropriate?<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(3) In Asterisk 13, we pulled in menuselect (yay). On the downside,<br>
Asterisk 11 doesn't have menuselect. What's more, Asterisk 1.8 and 12<br>
are still in security fix mode. We really have two options here:<br>
  (a) Update the build scripts to pull in menuselect as they do now<br>
from SVN, and more or less keep the existing process. My fear is that<br>
this may turn into a bit of hackery to keep the Git/SVN lines from<br>
getting confused.<br>
  (b) Bite the bullet and just backport menuselect into all the<br>
branches. Moving to Git is going to be a "breaking" change for people<br>
using Asterisk 11 anyway, and this way things end up in a reasonably<br>
pristine state.<br>
   Thoughts?<br></blockquote><div><br></div><div>(b) sounds the least painful overall to me. People consuming releases shouldn't notice a difference, right? </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(4) Asterisk records the SVN revision in each file using the special<br>
keyword "$Revision:". This is then registered in a linked list for<br>
retrieval by the CLI/AMI. Unfortunately, Git doesn't support this<br>
concept, as adding data into a file after commit would change the<br>
checksum . It does allow doing this on checkout via the $Id$ keyword,<br>
which may be an acceptable workaround.<br></blockquote><div><br></div><div> That whole thing seems questionably useful, anyway.  Just removing it is another option.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Anyway, the goal is to kick off the move of Asterisk to Git<br>
immediately after we get the next batch of releases out. I'll send out<br>
an e-mail once we know exactly when that is.</blockquote><div><br></div><div>\o/</div><div><br></div><div>-- </div><div>Russell Bryant </div></div></div></div>