[asterisk-dev] git migration update

[Paul Belanger]

On Mon, Dec 29, 2014 at 9:47 AM, Matthew Jordan <mjordan at digium.com> wrote:
> On Mon, Dec 22, 2014 at 9:01 PM, Tzafrir Cohen <tzafrir.cohen at xorcom.com> wrote:
>>
>> Hi,
>>
>> Thanks for the update.
>>
>> On Mon, Dec 22, 2014 at 01:03:17PM -0600, Samuel Galarneau wrote:
>> > Just wanted to update everyone on the git migration status and illicit some
>> > feedback on a few items.
>> >
>> > We setup an instance of Gerrit and Jenkins internally, imported the
>> > Asterisk testsuite into a git repo, and configured Gerrit and Jenkins
>> > together.
>>
>> Just a note: currently we have two pending "reviews" of patches by
>> private mails in dahdi: one in dahdi-linux and one in dahdi-tools. I
>> wonder when we can start using Gerrit.
>>
>> >
>> > 2 - we have a few options as far as team branches go. We could configure
>> > user branches using refs/heads/team/${username}/* permissions in Gerrit to
>> > allow users to create branches. This would prohibit other users from
>> > pushing to a user branch, but they would still be visible. This would most
>> > likely involve reproducing some sort of automerge/autorebase process. The
>> > other option is to use github as another remote for team branches, with a
>> > remote pointing to Gerrit for code reviews. Is there a preference between
>> > these two approaches, or perhaps a better setup we could follow?
>>
>> What if I have my own git server (which is not github)?
>>
>> But then again, why are team branches needed? When I work on my own
>> branch I keep it in sync with the main development branch manually. If I
>> don't work on it, it will fall back, but merging the changes (or
>> rebasing) should be easy with git. And if I want to work on someone
>> else's branch I can do this sync on my own.
>>
>> I don't think I'd want automerge. Autorebase is probably bad as you
>> can't clone that branch. If I rebase a branch I'd like to decide when it
>> is done.
>>
>
> So this point - is automerge necessary or not - is a large portion of
> what prompted Sam's original e-mail. In exploring git and our existing
> workflow, the automerge script itself turned out to be rather tricky.
> As he pointed out in his first comment, merely re-building the history
> from the various automerge properties has some complexity. The
> automerge script has its own complexities - should we be automatically
> rebasing branches? Should it instead cherry-pick commits? Neither
> option is terribly attractive, for different reasons.
>
> My inclination is that we won't know if we really need a git version
> of the automerge script until we've used git for awhile. I suspect
> that you are right, and that manually rebasing a branch is not much
> additional work (if any) over what is already required when using
> automerge.
>
> I'd propose that, at the very least, we ignore the automerge script
> portion of team branches until we know if we need it.
>
If people haven't tried my faux asterisk-testsuite git repo yet, I
would highly recommend doing so.  It would give you an example use
case for the 'automerge' script.  Since you are using gerrit (\o/) it
has the ability to merge code into branches.  However, there are some
issues gerrit does not take into account.

One of the way OpenStack Ci works around it, basically there is a
merge working branch (code in review) into master branch job that
fires each time.  If successful, the tests continue to run, if it
fails, then gerrit gives a -1 right away and no tests are executed.
Doing the same would be recommended.   It would be up to the developer
to away rebase against master then repost their code for review.
Then, when it comes time to merge the code, again there is a merge job
that fires, all tests are rerun and then gerrit eventually merges the
code into master.

-- 
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger