Simplified the changes so that #45 contains the minimal modified lines.

i brood about a convergence from

https://github.com/dotdevelop/dotdevelop/blob/e1b39ee2ea77f3c8ef513acb8c51e2c7037b2342/.github/workflows

and the wiki pages https://github.com/dotdevelop/dotdevelop/wiki/Setting-up-a-Build-Environment
and the packaging (=making .deb etc etc.)

a possible solution could be a pattern like in

https://github.com/libgit2/libgit2/tree/main/ci

where they refactored out the steps into separate steps for different distris

this could be reused in several steps:

• ci
• packaging (.deb, ...)
• wiki

all this should be happened in a repo similar to
https://github.com/dotdevelop/linux-packaging-monodevelop
with ideas merged from
https://github.com/libgit2/libgit2sharp.nativebinaries
there all the distri-CI's run and package

the
.github/workflows/monodevelop.yml
should only use ubuntu-latest
to keep checking of changes short-timed

the .github/workflows/monodevelop.yml should only use ubuntu-latest

And not check if each commit breaks older distros? I disagree.

BTW, I recommend not to use github wikis, as they are not changeable via git.

And not check if each commit breaks older distros? I disagree.

this is an upstream organization question

let on repo dotdevelop/dotdevelop branch main: stable build
let on repo dotdevelop/dotdevelop branch develop: build there commits are done, like in https://github.com/GtkSharp/GtkSharp
let repo dotdevelop/releases the (suggested) repo where all distri checks/packaging is done

then:

if on repo dotdevelop/dotdevelop branch develop seems to be ok, try it on repo dotdevelop/releases in a new branch, let it name branch dd/tryrelease/<version> or whatever (eg: dd/issues/<issuesolvednr> by updating the git submodule dotdevelop branch develop
if on repo dotdevelop/releases branch <branch name above> all checks on all distros are ok, merge on repo dotdevelop/dotdevelop branch develop into main
update on repo dotdevelop/releases branch main submodule dotdevelop to latest main

I cannot understand your last comment.

@knocte

BTW, I recommend not to use github wikis, as they are not changeable via git.

In what way? They work like a separate distro, so clone https://github.com/dotdevelop/dotdevelop.wiki works fine, then commit and push any changes (or issue a pull request). They are a bit of an oddity though, and easily overlooked.

@lytico

i brood about a convergence of the workflows ... and the wiki pages

I completely agree. The information should only be in one place (the workflows) and referenced by the README or wiki. At the time, I wasn't familiar with the workflows (and aren't really yet!), and intended the wiki pages to help a newcomer get started with building dotdevelop from whatever distro they used. I'll look at your suggestions and see if there's a better way, but in the meantime I'll keep the wiki pages updated.

As regards Issue #41, I favour forking into developers local branches and merging with pull requests, but more support is needed for reviewing and merging these.

so clone https://github.com/dotdevelop/dotdevelop.wiki

I didn't know this, however, seems one cannot access the history and commits and repo in the github interface, so the experience is still subpar IMO.

seems one cannot access the history and commits and repo in the github interface

wiki history can be found here: https://github.com/dotdevelop/dotdevelop/wiki/_history

I've just updated the Wiki pages to reference the CI workflow yaml file as the template for the basic software required, with the longer term aim of removing the individual Wiki 'Setup' pages. As there are a few pull requests pending for the extra distributions, I'll leave things where they are until these are merged (or a more comprehensive "packaging" reorganisation is done, as @lytico suggests). I'm beginning to think that Arch may not be worth including, as it's so different, but covering the main distributions that the mono-project and Microsoft dotnet support would definitely be worthwhile.

Github Actions and CI are fairly new to me, so please let me know if I've got any of this wrong.

the reason why i don't want it to have in the main, and the working branches, is, that for every commit it triggers a 20 min (and more) build action.

my suggested workflow would be:
main and working branches: build on linux latest
if it works here, try it in the build-repo ( or release or whatever it will be called) with all supported Linux etc. distris.