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. We do not want to worse their life quality, as they are the concrete walls on which ns-3 bases its life. 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): Answering of questions: 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.
Phase 3 (done): Live talks in wns3: In this week the proposal can be discussed live.
Phase 3bis (October): Google Hangout discussion on October 10, 15:00 UTC (contact firstname.lastname@example.org if interested)
Phase 4: 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.
Phase 1 (until 14 May)
Each ns-3 user is free to add questions that he/she would like to have answered. The objective is 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. In this way, I hope to catch early enough all the doubts and the driving decision in the design process.
- (nat) Should we move some modules to move to contrib?
- (nat) What modules should we move to contrib?
- (nat) Define how the contrib/ modules will be fetched and compiled
- (nat) Define the service we will use (GitHub, GitLab, BitBucket)
- (nat) Define the official branches (stable releases, development)
- (nat) Define how the versions are managed and released
- (nat) Define a workflow for integrating patches:
- (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
- (nat) Define the permissions of each user inside the projects (should everyone have r/w access to the repo?)
- (rediet) Define how issues/bugs will be reported (e.g. special rights needed?)
- (rediet) Will current features (currently managed through wiki) be handled by service (e.g. artefact)?
Add your question by prefixing your (recognizable) name. The questions can be reordered, and subtopic inserted until 14 May.
Each question of phase 1 will be answered.
Live talk at wns3
List discussion; voting if necessary on conflicting proposals