2

OAI_Dev_Call_20150616

Cedric Roux edited this page 2016-01-19 22:54:58 +01:00

Table of Contents

• OAI Developer Call (2015-06-17)
• Agenda:
• Meeting minutes

OAI Developer Call (2015-06-17)

The action items of the meeting are marked in BOLD. If anyone wants to join these bi-weekly meetings, please email Rohit Gupta or Raymond Knopp. We encourage discussion on the mailing list on the items discussed below to encourage better coordination of activities with the community.

Agenda:

1. Introduction
2. Discuss issues with usage of Gitlab@Eurecom if any (installation/configuration).
3. Workflow during SVN -> Git Migration
4. Git Workflow (branch structure and rules to commit) w/ general rules/guidelines of code contribution.
5. Assign owners for different parts of OAI Stack.
6. Documentation (doxygen, twiki, etc)
7. Integration of Jenkins, Gerrit, etc into Gitlab.
8. Unit tests for OAI
9. Regular meetings with External/Internal developers on the OAI Workflow (bi-weekly ?)

Meeting minutes

1. Introduction/Participants
   • Rohit, Florian, Raymond, Lionel, Navid, Cedric (Eurecom)
   • Ruben (Swisscom)
   • Carole (b-com)
   • Sebastian (IMST)
2. Discuss issues with usage of Gitlab@Eurecom if any (installation/configuration).
   • Any issues with downloading/checking in the code?
   • The current Git repo will be replaced with correct author names. It was there for test only. Pls Do Not checkin any useful code into Git Repo for now.
   • Note: The current gitlab repository does not have public access to the OAI community. But, we plan to change it soon.
   • History Cleanup of SVN Repo -> Current repo is too big
     • Proposal 1: Leave it as it is.
     • Proposal 2: Import only for last 2 years ? And delete large files and their history.
     • Proposal 3: Start clean copy from current SVN trunk. No history. However, we keep SVN server running for old history.
     • Proposal 4: keep all history and delete large files -> seems to be the best option.
     • AI: Rohit to look into cleaning the repo using https://rtyley.github.io/bfg-repo-cleaner/ . However, this step can only be performed after "transition period" (see below) to not conflict from SVN-to-Git Migration.
3. Workflow during SVN -> Git Migration
   • Git is read-only, All commits are carried out in SVN only
   • There is one way synch carried out every day from SVN to Git during "transition period"
   • After "transition period", once everyone is used to Git, we make SVN read only and Git becomes read/write repository.
   • The "transition period" is to make sure everyone is familiar with Git repository.
4. Git Workflow (branch structure and rules to commit) w/ general rules/guidelines of code contribution.
   • Example Proposal (based on idea from Ruben):
     • Master branch : Most stable (should never be broken). Contains last stable release
     • Maintenance branch: Carries out new feature integration, but still should work most of the time
     • Feature branches: Carries individual feature development. If two or more developers work on specific feature, they should merge their changes in one feature branch for easy history of repo and easy merging from branch admin.
     • Test branch: To carry out jenkis integration for individual features
     • Once feature is ready and updated with latest maintenance branch and passes tests on "jenkins" server, it can be handed over to "owners" of repo for code review and merge to "maintenance branch" using "pull" request.
     • Periodically we merge "maintenance" to "master" branch to mark OAI release once "maintenance" branch is deemed stable.
     • Merge from "maintenance" to "master" branch marks the milestone planning of OAI releases.
   • Carole: look at git branching model (http://nvie.com/posts/a-successful-git-branching-model/) -> lets try to adopt this model was the general consensus in the discussion.
   • AI: Rohit to make a working document (in twiki) on Git Workflow and OAI community at large can debate/discuss. It is important that Git workflow adopted by OAI is agreeable by the community at large.
5. Assign owners for different parts of OAI Stack.
   • The different owners are responsible for maintaining the stability/documentation of their part of the stack. The ownership is based on the current directory structure of OAI stack:
     • cmake_targets (Installation - cmake): Lionel Gauthier, Laurent Thomas
     • targets (oaisim, support for ExMIMO, USRP and other HW targets): Raymond Knopp, Navid Nikaein
     • openair1 (PHY): Raymond Knopp, Florian Kaltenberger
     • openair2 (MAC, PDCP, RLC): Navid Nikaein, Lionel Gauthier
     • openair3: Navid Nikaein, Lionel Gauthier
     • openair-cn: Lionel Gauthier, Navid Nikaein
   • Lionel suggests two people as minimum owners (primary and backup). We use a model based similar to linux subsystems.
6. Documentation Update(doxygen, twiki, etc):
   • doxygen is now working again with latest trunk using cmake.
   • update from authors based on latest trunk modifications
   • twiki will also undergo some modifications to reflect latest OAI code drop and will be more easy to browse.
   • Spend part of our time documenting the code to improve the user experience/reusability of the code from wider OAI community.
   • Establish how history of "code check in" should go in master repository so its easy to analyze and understand.
   • Coding guidelines document for different parts of the stack to efficiently merge changes from external developers
   • Sebastian: doxygen should remain on functional level -> mostly for developers
   • Navid: in addition to doxygen (openair1, openair2,...., etc) we should also have docs on the entire architecture, interfaces, tutorials, examples. -> mostly for end users
   • AI: Rohit, update doxygen with latest modifications in trunk. Collect architecture docs for OAI stack in order to establish the "big-picture" of the stack.
7. Integration of Jenkins, gerrit, etc into Gitlab
   • We do not need gerrit as gitlab already has code review built into it.
   • We do not need Jenkins as gitlab already has CI built into it.
   • Gitlab also has wiki in it. I will look into that as well to migrate twiki into gitlab.
   • We need to prioritize(?) which feature of gitlab to start integrating with OAI
   • All the workflow using gitlab (CI, code review, wiki) will be documented for facilitating collaboration within the OAI Community.
   • Carole: Have a look at https://about.gitlab.com/2014/09/29/gitlab-flow/ for more information.
   • ToDo for future meetings.
8. Integration of Unit Tests of OAI into gitlab
   • These tests must be passed before any commits within CI system.
   • Will help a lot to avoid broken trunk and improve stability of merges (esp from different developers).
   • Integrate CI with both unit tests and also with HW in future.
   • ToDo for future meetings.
9. Regular meetings with OAI Developer Community:
   • Meeting agenda will be sent out by the owner before the meeting.
   • Proposal: keep this meetings at first internal, (or at least a selected circle) but transparent (agenda + minutes on the mailing list).
   • There will be bi-weekly meetings with Eurecom and active participants in OAI community. We believe this will make decisions more efficient in a smaller group. However, meeting minutes will be sent out regularly. If anyone from the community wants to join the meeting, please send Rohit/Raymond an email and we can add you to the list.