Re: Postponing the July Meeting

Colin Finck <[email protected]> Thu, 2 Aug 2018 20:17:15 +0200

Newsgroups	gmane.os.reactos.kernel
Message-ID	<[email protected]>

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

_______________________________________________
Ros-dev mailing list
[email protected]
http://www.reactos.org/mailman/listinfo/ros-dev

signature.asc (application/pgp-signature, 819 B)