Freshrss: Drop dev branch, keep master only?

[marienfressinaud]

I noticed before the release of 1.15 that some people thought the project wasn't alive. Indeed, when we arrive on the GitHub page, we see the master branch which is updated only once in a while (3 months between FRSS 1.14.3 and 1.15.0). Also, the stats under the "insights" tab seem to only consider the master branch. I think it is a problem because it doesn't show off the real work we do on a daily-basis. Another problem I noticed is that GitHub consider the master branch for features such as the "sponsor" button, or to build the doc website. The last problem is that we are merging back master into dev after a new release, which results into very weird and unusable Git tree.

The core of this suggestion is to make the master branch a rolling release branch, as a replacement of dev. We already suggest to people to switch to this branch when we want them to test something and we are quite confident about its stability, at least because we are using it everyday with @Alkarex, so a bug never lasts too long.

I see two options to complete the suggestion:

1. we keep only one branch (master), drop dev, and use tags to mark the stable versions
2. we simply rename master into stable, and dev into master (that fixes most of the problems, but not the Git tree one)

My preference goes obviously to the first option. Its main drawback is that we need to ship all the last commits in the minor versions (what we already do actually).

The last option is to not change anything :)

Let me know what you think about this proposition.

[Frenzie]

All you need to do to fix the issue you raise is to make dev the default branch.

See my comments here:
https://github.com/FreshRSS/FreshRSS/issues/2657#issuecomment-553366096
https://github.com/FreshRSS/FreshRSS/issues/2657#issuecomment-553376436

As to just having a master and dropping dev, no objections here but that's a separate issue. :-)

[Frenzie]

[marienfressinaud]

Your solution is almost equivalent to option 2, but it doesn't fix the Git branch problem. Still, it's a solution, indeed :)

Another argument for option 1 is it simplifies the process to release a new version (no need to jump from a branch to another)

[aledeg]

I think we can drop the master branch and only keep the dev branch. Most people (including me) rely on tags to use the automatic update system. Some people want the latest version and use the dev branch. We can achieve similar process by dropping master and tagging dev.

I am not sure I understand your point about git tree.

[Alkarex]

I do not have a clear preference, but I agree that we need to do something.
@Frenzie 's suggestion would be an easy step, and equally easy to revert.
I like the possibility of having an overview of all files that have changed like https://github.com/FreshRSS/FreshRSS/pull/2655/files but this can be done between tags as well https://github.com/FreshRSS/FreshRSS/compare/1.15.1...1.15.2

[Frenzie]

this can be done between tags as well 1.15.1...1.15.2

I actually think that's more convenient for general comparison purposes because it works with hashes, tags, and branches alike. The equivalent for the PR you currently create prior to tagging would simply be https://github.com/FreshRSS/FreshRSS/compare/1.15.2...master.

The main point in favor of the dev/stable separation is to be able to put out a point release more easily when necessary. Personally I'm not sure if the extra effort is worth it, but as long as I'm not the one doing it I can hardly complain about it. ;-)

[marienfressinaud]

Since it seems we all agree that the (actual) dev branch by default is a good idea, I made the change :)

Concerning the branch problem, I mean this kind of merge:

It makes the history really difficult to read and to navigate into because old commits are getting mixed with the last ones.

[marienfressinaud]

It seems that you're also OK to keep just one branch (I think keeping a branch called master is better since people are used to it), let me know if I misunderstood! :) I think it will ask a bit more work so I'll take time in the next days to find the impacts and to make a PR (at least to update the documentation)

[Frenzie]

Would you mind holding off on the docs a little? #2590 is nearly done.

Alternatively you could just push to my branch (in English), although that would make the changes kind of blend in.

[Alkarex]

I have just seen the new https://github.com/FreshRSS/FreshRSS/packages?package_type=Docker
Not sure about the details yet (e.g. can it be automatised?), and whether that might have an impact on the decision here

[marienfressinaud]

@Frenzie No problem, I'll wait :)

@Alkarex I'm not sure to see how it would help :thinking: It basically replaces the Docker hub, isn't it?

[Frenzie]

@Alkarex Any CI can automate that kind of stuff with a token, but I'm guessing for whatever reason GH hopes you'll use GitHub Actions with GitHub Packages instead of Circle/GitLab/Travis CI with Docker Hub. Or maybe it's just a convenient backup for the moment, because everyone depends on Docker now. That way any potential future Docker Hub issues wouldn't have any impact on GitHub.

Like @marienfressinaud I don't understand how or why it would factor in though? It mostly seems a question of how much you want to depend on one single provider for everything without any practical distinction (at least for where the Docker images are hosted, of course slightly more so for one CI vs another).

[Alkarex]

Yes, my previous comment is probably unrelated to this issue indeed. As I have not looked into those options yet, I do not know whether some approaches could be made more automatic than others. To finish that parenthesis, I think having an alternative to Docker Hub can be nice, especially when the financing of Docker * is currently not so robust.

[marienfressinaud]

I took a quick look to the impacts in order to prepare the switch:

• it's mainly documentation that we have to adapt, nothing big, git grep dev will help (and so we're waiting for #2590)
• we'll have to remove dev build rules on Docker hub
• we'll also have to change the ZIP update system: nothing big, it's just changing the URL of the update_to_dev script

I think there is nothing to change on Travis.

[Frenzie]

On the first point, if you want to finish it up in full I should be able to translate the remaining French strings tomorrow, after which someone should correct them. Alternatively someone could translate them for me. But nothing is lost in just merging the PR. Compared to before, all the French has now been translated to English and some English has been translated to French.

Travis doesn't care about the branches (unless you instruct it not to build a particular branch).

[Alkarex]

Without the /dev vs. /master branch, one thing which might lack is the ability to easily release an urgent patch, but this might not be a show-stopper

[marienfressinaud]

I'll finish the switch tomorrow with the last tasks:

• [x] change default branch back to master in GitHub settings
• [x] merge dev in master
• [x] update PRs to be against master instead of dev
• [x] drop dev
• [x] remove dev build rules on Docker hub
• [x] change the URL of the update_to_dev script for the update server

[marienfressinaud]

It's all done :tada:

Don't forget to switch to master on your own instances :)

[SuperSandro2000]

Why can't you create branches for past releases and cherry pick patches into them? Should fix the history issue, too.

[marienfressinaud]

It is a solution indeed if we need it :+1:

[marienfressinaud]

Note that I changed master branch protection rules:

• disabled "dismiss stale pull request approvals when new commits are pushed" (in my opinion, once a PR has been approved, there are rarely big changes justifying a new approval)
• enabled "Require linear history"
• enabled "Include administrators"

Don't hesitate to argue if you disagree with one of these options (or even all :stuck_out_tongue: )

Here's the full configuration

[SuperSandro2000]

Can you please enable docker Alpine and GitHub pages? Those shouldn't break with a PR.

[marienfressinaud]

It's enabled now. The problem with checks from dockercloud is it takes a very long time to finish (~30 minutes). Just now I merged a PR so it triggered a build for master. I also want to merge another PR so I rebased on master and push to trigger new builds for my branch: if I'm right, I'll have to wait the builds to finish for one hour (for master, and then for my branch)

Edit: github/pages check was stuck so I disabled it for now

[SuperSandro2000]

Don't they run parallel?
I see the danger that the docker image breaks and no one notices it.

[marienfressinaud]

They do, but it seems we are limited to 2 parallel builds. I just realized that only the QEMU image takes ~30 minutes to build so I disabled the check for it. Still, it blocks a job for other builds.

[Alkarex]

It is not like one image is much slower to build than another. The more builds you ask Docker Hub to do, the slower it gets, much worse than in linear time, and depending on the time of day / day of week, so I guess it is priority based. I suggest to keep only the minimum auto-builds for branches, and full builds for /master

[Alkarex]

@marienfressinaud I have just disabled the option "Include administrators" to be able to force merge when tests are failing due a CI bug, or to avoid waiting a long time for tests that are not relevant (e.g. Docker tests in the case of a CSS pull request). We still get a clear red warning before proceeding. Let me know if you disagree

[marienfressinaud]

That was mostly for myself since I often merge with the CLI and I might miss the red warning. I'll just try to be careful.

Note about the CI bugs, we still can restart a build if it's temporary

[Alkarex]

@marienfressinaud Alright, I have also enabled signed commits, which is always the case from the Web interface

[Alkarex]

Ah, the signed commits option does not work the way I thought it would. Disabled again

[SuperSandro2000]

The signed-off stuff is annoying if you gpg sign your stuff.

[Frenzie]

Why, does GitHub break how it normally works?

[Alkarex]

@Frenzie I thought that with this option, one could Squash & merge from the Web interface (which is always signing) even unsigned commits, but that is not the case