GENIVI Git Strategy Meeting Minutes
lszafran at jaguarlandrover.com
Wed Jan 13 20:28:13 EST 2016
I wasn't yet subscribed to the mailing list when many of the original
emails were sent, so I'm going to be copying-and-pasting comments from the
archives and responding to them inline below. I'll try and preserve order
and indicate author. Hopefully it isn't too confusing.
(Paul) I wonder if it would make sense to add diagrams to the doc, based on
> what Lilli drew during the meeting while describing use-cases.
Sure, I can add some diagrams. And I updated the doc to be
(Paul) WRT the 'strategy' discussion I think there are some underlying
> approach questions, which need to be clarified:
> - how to deal with projects where we (genivi, agl) are not the ultimate
> upstream, but need to modify the code and maintain those modifications
> - github verses alternative approaches
> - code review via pull-requests (github, gitlab), or gerrit or
> something else
I agree that these are topics that my strategy doesn't explicitly cover,
but should be addressed.
In the case where genivi/agl isn't hosting the ultimate upstream: This is
probably a situation where trying to adhere to the master/develop branch
convention is more effort than it's worth. If we don't control a repo, even
if we need to maintain a copy with changes, it's probably less confusing to
use the originating repo's naming convention than trying to shoehorn in a
new one. That doesn't mean that we still can't use the
topic-branch-commit-hook part of the strategy. If you're doing any kind of
work, make a branch, and keep the changes atomic, tag the messages with the
branch name (hopefully linked to a system like JIRA). It might seem like
more work upfront, but it can make a big difference later, when trying to
see what project-specific changes where made to the repo.
Github vs. alternate approaches: I'm a fan of GitHub for several reasons,
but that's not to say there aren't other/better tools. GitHub does a lot of
powerful things, and it's quickly becoming the industry standard (if it
isn't already). Old-school, Linux, open-source projects seem to use it the
least, but start-ups, recent grads, open-source projects, etc., all host on
GitHub. More people are used to GitHub, and a GitHub-based workflow, than
any other tool, and the group of GH users will only continue to grow.
How to do code reviews: This is a good question. My document doesn't really
touch on this step, but it's far too important to ignore. We should discuss
On Wed, Jan 13, 2016 at 1:55 PM, Walt Miner <wminer at linuxfoundation.org>
>>> (Magnus) DISCUSSION - ENFORCABILITY
>>>> Jeremiah highlighted the wide variety of projects GENIVI is running in
>>>> several different environments, and pointed out that it can be hard
>>>> for people to move from todays patch-based solution to something that
>>>> is pull request-based.
>>> (Paul) Absolutely - this depends very much on how the project team
>>> prefers to work.
>> (Jeremiah) Here's one example of the type of workflow that I was
>> referring to when I spoke about a "series of patches", the following is an
>> excerpt from this page:
>> [PATCH 0/3] Proposal of ivi_share protocol Tanibata, Nobuhiko
>> [PATCH 1/3] protocol: Add new protocol to share ivi-surface Tanibata,
>> Nobuhiko (ADITJ/SWG)
>> [PATCH 2/3] ivi-share: Initial implementation of ivi_share protocol.
>> Tanibata, Nobuhiko (ADITJ/SWG)
>> [PATCH 3/3] ivi-layermanagement-examples: an example of ivi_share
>> Tanibata, Nobuhiko (ADITJ/SWG)
>> This series of emails, each with its own numbered patch, is much easier
>> to deal with than a single large patch for example. While one can easily
>> break up pull requests on GitHub as well, there are additional advantages
>> to this format. Firstly, git provides convenient tools to create this type
>> of patch set: https://git-scm.com/docs/git-send-email Secondly, it also
>> provides a means to consume such patch sets;
Correct me if I'm wrong, but I believe that the "email patch" workflow
preserves commit messages, correct? Or it, in theory, could, if the sender
and receiver did everything correctly. If that's the case, then I don't
know if we'd need a "patch" branch, and we can still get all the same
benefits of using my proposed workflow:
- *The master/develop naming convention* - By creating two branches, you
allow a project's development to continue unhindered, while also providing
a place where people can go and get code that they know to be tested,
reliable, and stable. Of course, this can be achieved in more ways than
using a develop/master branch, but using this naming convention keeps
everyone on the same page. Develop is a place where untested, unreleased,
in-development code can be shared between people before officially
releasing. People can keep working on the develop branch during a
code-freeze/release. Master is always stable.
- *Doing work on topic branches, naming them after JIRA (or whatever)
tickets, and tagging their commit messages* - Doing this keeps work
atomic, and links the work to a place where more information can be
obtained (descriptions, reproduction steps, acceptance criteria). It makes
the Git history much easier to read, and helps map the work-completed to
the ticket describing it. It doesn't matter how the work is merged back in
to develop. We can still use topic branches w properly-formatted commit
My process refers to pull-requests, because I wrote it for an audience who
only knows GitHub. But the advantages gained by the workflow are gained
regardless of how commits are merged.
For those who spend a lot of time in git and working on mailing lists
>> (which is pretty much the de facto approach for large Open Source
>> projects), this work flow is efficient. I don't know that GitHub provides a
>> similar workflow and I would hesitate to try and dictate tooling choices
>> for developers who are productive.
I agree completely; we shouldn't dictate tooling choices for productive
developers. I believe there's a solution that satisfies everyone.
WRT GitHub-as-an-intermediary solution, Paul brings up a few good points as
to why that could be problematic:
(Paul) One problem I would hope we can avoid is the multiple upstreams
> situation, where for a new community member it's not obvious which
> copy/fork/mirror is the main source for the project. There was some
> confusion about this recently where, for example, one of the Yocto repos
> was being actively developed in two other (github) places as well as
> git.yoctoproject.org, which created some confusion and friction.
Again, maybe, depending on what you mean by intermediary. We didn't talk
> about the question of provenance, for example. IMO
> provenance matters, and I think some folks agree. It would be a mistake
> if introducing an intermediary made provenance harder to establish.
This may not be correct... I've yet to come across an engineer who
> wouldn't *prefer* github vs the current GENIVI-hosted git server...
I wasn't around when git.genivi.org was established, but maybe we could
> actually persuade folks that github is the best way now, with a bit of
> pressure and maybe alcohol :)
Remind me again why the projects' main upstream should be on the genivi
servers, versus the genivi servers mirroring GH, and GH being the main
upstream? Or is that a solution that everyone likes?
I believe these are our choices:
- Genivi servers are the main upstream, no GH intermediary
- Genivi servers are the main upstream, w GH intermediary
- GH as the main upstream, genivi servers mirroring GH (with deployments
to genivi servers triggered on merges to master/develop/etc. or something)
There are a lot of advantages of using GH as the main upstream, except for
the fact that I don't believe submitting patches by email is possible. I
think it would force projects to adhere to pull-requests mechanism as the
only option, and I'm not sure if everyone would be on-board. Unless emailed
patches are applied to a maintainer's local repo, then pushed directly to
the GH's upstream account. I believe authorship is preserved.
I think using GH as an intermediary does increase confusion, but allows us
all the advantages of GH.
Cutting GH out of the loop entirely doesn't feel like the right solution. I
think you'd lose far too many potential contributors who would be
unfamiliar with old-school Linux open-source practices such as emailing
patches, and who might be intimidated by genivi git server's interface.
>* (Magnus) Implement develop branch in git.genivi.org
> <http://git.genivi.org>  and use master *>* purely as a release branch
> (see doc). *
(Paul) I'm not sure about this, but maybe I'm misunderstanding the
> document. As I understand it many successful projects (including Linux
> itself) do
not follow the approach described.
Yes, it is true that many successful projects don't do this. And there are
several other analogous strategies/conventions that a project can use to
achieve the same benefit. This branch strategy/naming convention gives you
repo a place where ongoing collaboration can happen unimpeded by
code-freeze/testing/releasing... It gives a place for people to go to get
either the latest code or stable code... Hot-fixing the master code is
simpler: if a bug is discovered in stable code, you can patch master, merge
the patch into develop, no crazy rebasing or people needing to grab
unstable code to get the fix... You can write git-hooks to automate things
when commits to master are made... Etc.
(Walt) Will there be any follow up to this? I will say I like the gerrit
> approach because it encompasses both branch management and code review. You
> can incorporate email patches into the work flow as well.
Can you clarify Gerrit and it's branch management? Where would this fit
into the overall process?
Mobile Architect - Infotainment
*Email:* lszafran at jaguarlandrover.com
Jaguar Land Rover North America, LLC
1419 NW 14th Ave, Portland, OR 97209
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the genivi-projects