So, to make all our stuff easier to manage and build in a homogeneous way. The idea was there to split out the packaging scripts into a separate repo.
This is an implementation proposal of that. Please leave your comments/suggestions/critique/other proposals below. This really adds some complexity for us now, but this should make the bar of entry for new developers and users that just want to build, much easier.
We would have one main entry repository with more ‘child’ repositories. There will be no submodules, anywhere.
The main repository contains the packaging scripts and everything required to build the full project. The main build script will either take an existing repository path or clone the required repository into its own directory. This gives existing developers the flexibility to have their repositories any place they want.
The main projects script will handle cloning or building any dependencies of the chosen target, so for example if the server is being built and the web repository has not yet been cloned or build, it will do that first, given the configuration constraints specified on either the command line or a configuration file. This configuration file will also help with making sure that if you have your repository in a location that is not the default you will not have to enter it in the terminal every time.
This is the repository where all the server code lives. It contains all source files to build the server binaries and the build system (dotnet/MSBuild) that is required. A functioning install will need the files from the
jellyfin-web repository. If people do not want to use the main repository to set it all up for them, they can manually point their server binaries to the place the files are located if the suggestion in  is implemented.
This is the repository where all the webclient code lives. It will contain all files required for it’s own build system (yarn+webpack).
Any other repository ex:
Any other repository containing a specific client or plugin for example can be built using the same methods and the main server binaries or the web application. This would mean that in the end, and if run on a supported platform. There will be a make me everything command, building every supported project for the target platform or all supported platforms.
Active development options
The main build script by default should shallow clone every repository at the last tag, but for development a regular clone is required. This would be configurable when bootstrapping the main repository the initial time and be written to a configuration file. This could even be done interactively.
This would also be able to setup the correct paths for development on different parts, if required.  This ensures that testing for example web changes does not require one to recompile the whole server. But instead only a browser refresh.
 Adding a command line argument to configure the root of the web files to the server will help this along even more. An other option is using an environment variable, for this and other paths.
 Think about a
docker-compose.yml file, to specify the correct paths to volumes automatically and to make developing as easy as calling
docker-compose up. The same effect can be realized for non docker development aswell.
These are just some of my quick thoughts. I definitely missed stuff from the matrix discussion, so if you miss anything, just write below.