Suggestion for modules: cmake properties (and default value): DISABLE_ROSTESTS:bool=false ENABLE_ROSAPPS:bool=false

Since we can call cmake with -DENABLE_ROSAPPS:bool=true in the commandline, to override the default, it's easy to toggle.

As for other modules:

Documentation deserves its own repository, at github.com/reactos/documentation, where people can more easily contribute documentation separately from code.
Rossubsys: I'd extract them into some git repository at like git.reactos.org/rossubsys.git, for anyone who wants to access them historically, but I wouldn't bother making a github repository for them.
Wallpapers: Would be nice to have a community website where people can submit wallpapers, themes, cursors, icons, ... and the "staff picks" can get copied into modules/wallpapers and included in releases.

On 7 September 2017 at 19:17, Colin Finck <colin@reactos.org> wrote:

Hi all!

As you know, we have to give up our "modules" directory concept when switching to Git, because Git doesn't support checking out an arbitrary directory into a subdirectory of a Git clone.
Therefore, the first commit to the migrated repository will make the "reactos" directory the new root and move "rosapps" and "rostests" permanently into "modules". We can then introduce an environment variable/CMake variable/something else to enable or disable building of them on demand (suggestions are welcome!)

But what will happen to the remaining directories in /trunk, namely "documentation", "rossubsys", and "wallpapers"?

* Commits to "documentation" never had a relation to "reactos" commits, so nothing is lost if we put that directory into a separate repo "documentation.git" and remove all traces to it from the history of "reactos.git". I'd go this way if there are no objections.

* I don't get the idea of that "rossubsys" directory created in 2014.. These subsystems are all stubs, never built with modern ReactOS, and no work has happened since "reviving" them. I would just go and remove them again. You can always find them in our repository history.

* The "wallpapers" directory is a harder candidate.
On the one hand, we don't want to bloat our ReactOS builds by including wallpapers in every build. Also the number of wallpapers may increase in the future, which could bloat the "reactos.git" repo even more.
On the other hand, the wallpapers have always accompanied our release branches, so there is a value of having them tracked next to our code.

I could put them in a separate repository "wallpapers.git" now and remove all traces to them in the "reactos.git" repo. But then again, how are they picked up by the build process in the future if we can't check them out into a subdirectory of "modules"?
Another alternative is moving them to "modules/wallpapers_disabled". Then they are not picked up by the build process until they are renamed to "modules/wallpapers" for releases.

What are your opinions on this?

Cheers,

Colin

_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev