Am 01.08.2018 um 20:16 schrieb Ged Murphy: > I have an item for the agenda. I'd like to discuss the possibility of moving > some of our drivers out of the main repo and into something more convenient. > [...] > If we're going to do that, why not consider others too. Network cards, sound > stack, USB, boot loaders, printer drivers, directx, etc
Using Git submodules to make ReactOS more manageable and increase its exposure was also my ultimate vision prior to the Git move. However, after a vivid discussion back then, we had damn good reasons for sticking with a Monorepo. First, take into account that Git submodules come with their own drawbacks: 1) If you branch from "master" in our "reactos" repository, its submodules will stay on "master". In a branch workflow, you basically have to create a branch for each submodule you want to touch and then update submodule links. 2) Git always checks out submodules at their root paths. There is no way to include just a subdirectory of a submodule. This can be problematic if you want a submodule to make sense on its own and as part of the big "reactos" repository at the same time. 3) You need more commits to achieve the same, because you first commit into the submodule and then commit to "reactos" to update the submodule link. This can be annoying when there are lots of submodules. There are alternatives like "subtrees" and Google's "repo" tool, but they come with their own drawbacks, most notably worse support from our toolchain. People involved back then may check out the "Reactos Git migration plan" and "Git Migration Decisions" Google Docs files from that time, as well as the mailing list discussions. There are also numerous blog posts about failed migrations to Git submodules. Let me quote from our decisions back then: * "There are no modules yet that can be built on their own or which are big enough to justify a split from the main repository at this point." * "components should only be split into separate repo if the component factored out is useful on its own [and] if the component is HUGE and optional" So if people still want to split off components into separate repositories, we first have to do our homework. In my opinion, this includes: * Providing a minimal CMake-based ReactOS SDK that can compile both a single component like Paint and the entire OS. * Deciding on a generic structure for each submodule to come: README.md, directories, where bugs are filed, Continuous Integration For the bugs part, we could actually create a JIRA project for each submodule and move existing bugs there. Regarding Continuous Integration, our BuildBot should be made more flexible to accept in-tree configuration files (like Travis-CI). It would then be able to serve standalone projects as well. BuildBot 0.9.x supports "BuildBot Travis" for that. Of course, we could also go fully Travis-CI/AppVeyor, but then we're in serious trouble if they ever cease service. Additionally, jobs may be queued for a long time if their servers are overloaded. Finally, always consider whether a module serves a real purpose on its own. For instance, BTRFS is something Windows doesn't offer, so it has a huge exposure on GitHub. On the contrary, NTFS is something Windows can usually do better, so our own NTFS driver may hardly be popular as a separate project. However, I would love to be proven wrong on this! Best regards, Colin
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
