7 Sep
2017
7 Sep
'17
5:26 p.m.
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(a)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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev