... | ... | @@ -99,7 +99,7 @@ When a software project moves from a forge to another, it is not just about the |
|
|
|
|
|
When on-boarding new developers, it is useful to browse the discussions from older issues to understand how a particular part of the codebase came to be. This is also true for pull and merge requests, forums and mailing lists. Even the CI artifacts and the description of the CI: a complex pipeline that relies on features specific provided by a given forge (ref. ZA22) (ref. DA35) (ref. AM28) may be difficult to migrate to another forge that does not support them (for instance moving from [travis](https://docs.travis-ci.com/user/tutorial/) to [GitLab CI](https://docs.gitlab.com/ce/ci/yaml/README.html)).
|
|
|
|
|
|
The scope of what defines a software is fuzzy (ref. ZA19) (ref. PO42) (ref. CJ44) and should be considered on a case by case basis (ref. PO39). It is a web of dependencies that are not confined to the boundaries of a forge (ref. AR17) (ref. NA16) (ref. DA52). It includes every data, web service and developer that is stored and put to work when the software project moves forward. As an example, a developer mentioned that when they want to modify a software they use on their machine "most of the time it is not installed in a way that allows modifications: the first step is to get the code. If it's a Debian package, I look into he package metadata to find the source code, if it is a Python project, I tend to look on PyPI: I rely on the package manager to locate the source code" (ref. ZA11). Another example is how the software is packaged and distributed as it often involves resources external to the forge (ref. AR20).
|
|
|
The scope of what defines a software is fuzzy (ref. ZA19) (ref. PO42) (ref. CJ44) and should be considered on a case by case basis (ref. PO39). It is a web of dependencies that are not confined to the boundaries of a forge (ref. AR17) (ref. NA16) (ref. DA52). It includes every data, web service that is stored and put to work when the software project moves forward. As an example, a developer mentioned that when they want to modify a software they use on their machine "most of the time it is not installed in a way that allows modifications: the first step is to get the code. If it's a Debian package, I look into he package metadata to find the source code, if it is a Python project, I tend to look on PyPI: I rely on the package manager to locate the source code" (ref. ZA11). Another example is how the software is packaged and distributed as it often involves resources external to the forge (ref. AR20).
|
|
|
|
|
|
The forge features used by a software project as well as its scope depends on how many people work on it. Very large projects tend to use more features and some tiny projects only have a DVCS (ref. NA22).
|
|
|
|
... | ... | |