Difference between revisions of "Git Migration"

From Nsnam
Jump to: navigation, search
(update)
(update Git migration page)
Line 2: Line 2:
 
This page recap all the open questions for the migration to the git tool for managing source code and their answers.
 
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.
+
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 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.
Line 8: Line 8:
 
'''Phase 2 (done)''': ''Live talks in wns3: '' In this week the proposal can be discussed live.
 
'''Phase 2 (done)''': ''Live talks in wns3: '' In this week the proposal can be discussed live.
  
'''Phase 3 (October)''': ''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 tomh@tomh.org if interested).
+
'''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 tomh@tomh.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 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.
 
'''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.
Line 16: Line 16:
 
= Phase 1 =
 
= Phase 1 =
  
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.
+
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?
+
# (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?
+
# (nat) What modules should we move to contrib? <- None
# (nat) Define how the contrib/ modules will be fetched and compiled
+
# (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)
+
# (nat) Define the service we will use (GitHub, GitLab, BitBucket) <- GitLab
# (nat) Define the official branches (stable releases, development)
+
# (nat) Define the official branches (stable releases, development) <- See workflow discussion below
# (nat) Define how the versions are managed and released
+
# (nat) Define how the versions are managed and released <- See workflow discussion below
# (nat) Define a workflow for integrating patches:
+
# (nat) Define a workflow for integrating patches: <-  See workflow discussion below
 
## (nat) stable fixes (fixes that are for an already shipped version)
 
## (nat) stable fixes (fixes that are for an already shipped version)
 
## (nat) development fixes/features (fixes and features for master branch)
 
## (nat) development fixes/features (fixes and features for master branch)
# (nat) Define the accepted code review models
+
# (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?)
+
# (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?)
+
# (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)?
+
# (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.
  
''' Add your question by prefixing your (recognizable) name.''' The questions can be reordered, and subtopic inserted until 14 May.
+
(skipping now to phase 5)
 
+
= Phase 2 =
+
Live talk at wns3
+
 
+
= Phase 3 =
+
Each question of phase 1 will be answered.
+
 
+
= Phase 4 =
+
List discussion; voting if necessary on conflicting proposals
+
  
 
= Phase 5 =
 
= Phase 5 =
 
Implementation
 
Implementation

Revision as of 19:47, 25 November 2018

Git Migration

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 tomh@tomh.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.

Phase 1

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.

  1. (nat) Should we move some modules to move to contrib? <- No; this can be done as a subsequent step
  2. (nat) What modules should we move to contrib? <- None
  3. (nat) Define how the contrib/ modules will be fetched and compiled <- Using bake or plain download
  4. (nat) Define the service we will use (GitHub, GitLab, BitBucket) <- GitLab
  5. (nat) Define the official branches (stable releases, development) <- See workflow discussion below
  6. (nat) Define how the versions are managed and released <- See workflow discussion below
  7. (nat) Define a workflow for integrating patches: <- See workflow discussion below
    1. (nat) stable fixes (fixes that are for an already shipped version)
    2. (nat) development fixes/features (fixes and features for master branch)
  8. (nat) Define the accepted code review models <- GitLab Merge Review, others (GitHub, code review) can still be used
  9. (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
  10. (rediet) Define how issues/bugs will be reported (e.g. special rights needed?) <- Will migrate to GitLab tracker
  11. (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.

(skipping now to phase 5)

Phase 5

Implementation