Version v3.8.0 and moving from develop to master

[BFH-ktt1]

Dear all,

There are some issues that I see in the moment that I would like to put out for discussion:

1. We are way behind the release of V3.8.0 due to some PR's that are still blocked, whilst they have been "fixed" already quite some time. I understand that we (as me also) have periods where we cannot spend time on the project, but I am asking myself if the current system put in place is the way to go. Maybe there should be an "overide" policy in place.
2. There are several remarks concerning working in development and only having the releases in master. I have no problem to move develop to master, and have branches of master being the "releases". This would mean the we merge the current develop in master, "remove" develop branch and use RC-branches from master for the different versions. What is your opinion on that?

Any input from you all would be appreciated.

[BFH-ktt1]

For the moment I advanced on the discussion and overruled some blocks on PR's.

[davidhutchens]

1. It is appropriate to allow a review who requests changes to review the changes. But if changes have been made and that reviewer has not responded in some reasonable time (3-4 weeks?) then another reviewer should be able to decide if the issue has been adequately addressed. So I support your idea of an override policy.

2. New contributors are sometimes confused by our develop branch. Github seems to favor using master as the development branch. For example, it uses master as the default target for PRs. Also consider the comment in Corrected nightly builder #1557 about whether the PR should be targeted to master. Changes to the Readme are not currently shown on the project page until they are merged into master. Usually, we would be happy to have them appear as soon as approved. There may be cases were a change should wait until a release, but we could deal with that by holding the PR until we ready for the next release.

There are several things that would need to be changed if we make master our development branch. The Readme would need to be adjusted. Workflows currently targeting develop would need to be checked and adjusted. We will likely be discovering things for a while.

Overall, I lean toward making the change. Even though it will cause some immediate issues, I think it will be somewhat simpler in the end.

[davidhutchens]

Having looked at some of the workflow issues with dependabot, I suggest we consider switching the default branch of the project from master to develop. By switching the default branch, our workflows should largely work unchanged. It might even allow us to fix nightly to just be nightly (#1714). We would continue to work on the develop branch. Further, all our documentation already says to submit changes to the develop branch, so the documentation would not need to be changed much either. When we have that working well, we could then delete the master branch and just maintain develop and the latest release branch(es).

The one thing I'm not quite sure about is how this would impact forks. Does anyone know? The amount of work for each of our many forks should be considered in choosing 1) develop on master, 2) switch default to develop, or 3) keep working as we have been.

How do others feel about this?

[R3dst0ne]

Working primarily in the develop branch has lead to problems with the GitHub workflows in the past and as mentioned by @davidhutchens there are some things that possibly can only be solved by changing the main branch or moving the development to master.
Additionally, there have been concerns that it currently looks like LSe is not in active development (#1495, #1502).

(If we decide to change the main branch, it might be the right time to look into #810 again.)

[davidhutchens]

I noted in #1768 that having the default branch match our development branch brings easier and more useful workflows because that is the assumed arrangement in github projects. I think it is time to make that change. I noticed in looking at documentation and projects for CodeQL that many projects now use the name main for that branch. I agree with @R3dst0ne that it makes sense to follow that trend as well. We might as well do all those things at once so we only have to clean up once.

[BFH-ktt1]

I renamed our develop branch to main and made main the default branch.
to change locally:

git fetch origin
git branch -u origin/main main
git remote set-head origin -a```
I hope we won't have too much side effects :-)