This page recap all the open questions for the migration to the git tool for managing source code and their answers.
We all agree on the fact that a giant, important step like this requires coordination, and the feedback/contribution of many people as possible, especially current maintainers. The process of updating the source code management system will be split into different sequential phases. Each phase will be used as input for the next stage.
Phase 1 (done): Definition of questions to be answered: Each ns-3 users can put questions on this page that he/she would like to have it answered. The problems can have multiple points. Users can add points to each item.
Phase 2 (done): Live talks in wns3: In this week the proposal can be discussed live.
Phase 3 (done): Discussion of options: Each developer starts answering the questions (even not his/her own) with his/her proposal. Each proposal can be refined, discussed on the mailing list, and so on. Plan to do this at Google Hangout on October 10, 15:00 UTC (contact firstname.lastname@example.org if interested).
Phase 4 (done): list discussion: If there are questions with conflicting proposals, the current maintainers will have a vote on what plan should be implemented.
Phase 5 - Implementation: The maintainers will start migrate the source code. At the end of the phase, the community will give comments. Discuss, integrate, iterate until final release.
Each ns-3 user was free to add questions that he/she would like to have answered. The objective was to have a coherent set of stakeholder interests, as well as a set of design rules that take into considerations these interests. The reality is that we have a different way of working, and it is difficult to have something that is good enough for everyone. Below were the questions raised and conclusions later drawn.
- (nat) Should we move some modules to move to contrib? <- No; this can be done as a subsequent step
- (nat) What modules should we move to contrib? <- None
- (nat) Define how the contrib/ modules will be fetched and compiled <- Using bake or plain download
- (nat) Define the service we will use (GitHub, GitLab, BitBucket) <- GitLab
- (nat) Define the official branches (stable releases, development) <- See workflow discussion below
- (nat) Define how the versions are managed and released <- See workflow discussion below
- (nat) Define a workflow for integrating patches: <- See workflow discussion below
- (nat) stable fixes (fixes that are for an already shipped version)
- (nat) development fixes/features (fixes and features for master branch)
- (nat) Define the accepted code review models <- GitLab Merge Review, others (GitHub, code review) can still be used
- (nat) Define the permissions of each user inside the projects (should everyone have r/w access to the repo?) <- Use GitLab groups to manage access
- (rediet) Define how issues/bugs will be reported (e.g. special rights needed?) <- Will migrate to GitLab tracker
- (rediet) Will current features (currently managed through wiki) be handled by service (e.g. artefact)? <- Keep wiki and static server, start to use GitLab features (CI/CD, GitLab pages, tracker) over time.
Phases 2, 3, 4
Historic details omitted herein but after discussion throughout the summer, including list discussion and offlist maintainer discussions, and testing of three popular cloud-hosted services (GitHub, GitLab, Bitbucket), decision was taken to use GitLab cloud (GitLab.com) as hosting service.