Android™ Automotive SIG
Multi-OS Integration Project
Domain Interaction Projects
Cloud & Connected Services Project
GENIVI Github Repository
GENIVI Code Project Descriptions
GENIVI Yocto IVI Baseline
This post is for the "how" of the migration, not the "why". You can also view these email threads for reference and background: http://lists.genivi.org/pipermail/genivi-projects/2016-April/002039.html and http://lists.genivi.org/pipermail/genivi-projects/2016-May/002216.html
These repos are mirrored on a new server in JLR's Portland facility. The repos will be switched to "read only" so that we do not get updates to separate git repos. New development should happen at GitHub, the old repos remain for two years to provide a link for older versions of the GENIVI Compliance Specification and for convenience for automated software builds. As we turn the git repos from write to read only, we'll also be deactivating the public ssh keys associated with the accounts on the repositories. This is for security purposes.
No, it shouldn't be. The point of making the GENIVI mirror use the same URLs was to preserve access for Yocto layers and recipes, as well as other tooling like baserock. If you want the latest and greatest GENIVI code, it might be best to look at GENIVI's GitHub account.
When repos are put onto GENIVI's GitHub account they automatically become part of the GENIVI GitHub space. This is reflected in the URL for example, as well as other places: https://github.com/GENIVI/capic-poc Everything under https://github.com/GENIVI/ is part of GENIVI. GENIVI has an organizational account at GitHub and is responsible for the terms of service agreement with GitHub.
No. Pushing to git repos, that is to say developing new code, will be done at GitHub. There may be a way for GENIVI to set up push access but this is only for certain situations where GitHub's terms and conditions are unacceptable.
No, we inherit GitHub's look and feel. There is a substantial API however so we may be able to create our own look and feel if wanted.
Yes. I wouldn't conflate the terms "account" and "maintainer" though since GitHub uses those terms differently than we do. We can create numerous accounts and transfer maintainership between them as well as use team based access control, in fact we're doing that now.
Yes, you can have more than one maintainer. The best practice is likely through team maintainership. By adding multiple maintainers to a team you can easily have more than one maintainer. You can also limit each team member to a specific set of functionality, like read-only, or write and push, and even able to create new team repos. Teams can be created around any repo, or set of repos, and can contain one or more GitHub accounts.
It might be nice if you made your membership in the GENIVI organization 'public' – it is by default private when you are added as a member in the GENIVI Organization in GitHub. Making the association public makes your belonging to GENIVI visible on your personal GitHub page. Also, adding two factor authentication is a good idea for protecting both your account and GENIVI. Add an avatar as well to easily identify contributors.