@GrahamcOfBorg test gitea

@tomfitzhenry Yes... This is quite hard because since 1.10 is out 1.9 is now unmaintained.

And if any security related problems are found in 1.9.x, gitea won't release a 1.9.x-series release to address this. They just expect people to upgrade to latest instead.

The reasoning gitea has for this is that it's a small community project that doesn't have the resources to maintain LTS releases.

And most of nixpkgs is maintained by contributors that don't get paid either, so we don't really have the resources to do backports of patches to address certain issues.

During the 19.03 cycle we did a backport of 1.7->1.8 or something like that. Something broke with locales because it was only copied on the first start. But that has been fixed in the service. But sure, other things can show up.

I'm on the fence on this. But the maintainer requested a backport so I made a backport PR for @kolaente to review at least.

I really wish gitea would advertise itself the fact that they have no ability to support LTS as users might not understand the implications of hosting the software...

@tomfitzhenry if you're behind a private network and have a trusted set of users you could make use of https://nixos.org/nixos/options.html#services.gitea.package

@etu maybe we should consider mentioning something about no LTS in the options documentation.

@aanderse You're right, we should advertise this more. I'll talk with the other maintainers about the option of at least supporting the last release with security fixes. We had some of that discussion in the past, and decided to not release an LTS version because of the reasons mentioned by @etu.
Since this was some time ago, it's maybe time to re-evaluate.

Another (workaround) option would be to not merge this until there is a security issue with 1.9.6 and then merge this. That way, we would keep breaking changes as long as possible from entering 19.09.

Where exactly is the problem with updating to version 1.10?

Standstill means simply postponing the effort until later. At some point you have to do it anyway.

Who guarantees a quick fix to the old version? If a bug in the current version is no longer present but in the old version it is, who controls this? Maybe bugs have been fixed, which were not made public?

Not doing updates is not a good option in my eyes.

If you choose a stable release, then you expect something that keeps working and potentially has fixes over time for issues you've accepted from the beginning on. A release that changes behavior in its interface is thus from a stable point of view a regression (hence the minor version increase). That outweighs fixes for issues you've accepted from the beginning on.

So, what should we do here? I would propose to get 1.10 into stable for all the reasons discussed before.

Meanwhile, there is a Bugfix release 1.10.1: #75066
Should I cherry pick from there?

Generally I agree with @FRidh but if upstream isn't supporting a their old code I think they need to advertise that better... and we can then too. I see gitea fit into that category of bleeding edge software you shouldn't use unless you are alright with keeping up to date and dealing with occasional breaks.

I haven't convinced the team at work to ditch gitlab for gitea yet, though, so my opinion only goes so far... 🤷‍♂️

We currently also bump gitlab versions on 19.09 the same as we do on master (mostly due to lack of manpower, even though gitlab provides stable releases), so I assume it's even more fine to do with gitea as well, if they don't even provide stable releases.

@etu, can you cherry-pick #75066 into here?

@flokli No problem and done! :)

@GrahamcOfBorg test gitea

I still don't see an actual need to upgrade the package. Are there any security fixes that necessitate an upgrade? As far as I can tell not. Anyone that wants the unstable version can easily import a newer nixpkgs and set gitea.package or use a container for it. Then they can choose for themselves whether they can handle the API changes, instead of having those forced upon them, on a stable release.

Regarding gitlab updates on stable #74978

@FRidh a bit off-topic, but the linked issue was a bug causing nix store paths to be persisted in state files. I don't really see how this is an argument in favor or against update policies - it was broken all the time, and a NixOS specific patch was added to make these entries more stable for all newly inserted entries. It didn't have anything to do with the GitLab version that was used - it did break every time store paths were garbage collected, and entries referred to an old version of gitlab-shell.

Regarding gitea:

I agree if there are no imminent security issues with the current gitea version in stable, it could stay at that version - as you described, people could always pull in things from unstable by passing a custom gitea.package.

However, I also wouldn't strongly advocate against the maintainers of the gitea package to decide to just keep it in sync with master (There were some security issues without CVEs issued in gitea in the past). I'd leave that decision to them.

I wouldn't assume gitea breaks API on purpose, same for GitLab.

What happens if NixOS 20.03 wants to update from Gitea 1.9.6 to a future version 1.1X.Y? Who guarantees that this will work?

Current master (which will become 20.03) is already at 1.10.2, so NixOS 20.03 already has updated according to your scenario.

Between NixOS releases we reserve the right to make (and document) breaking changes, especially if upstream forces our hand.

Does this adequately answer your question?

Current master (which will become 20.03) is already at 1.10.2

Assuming with release NixOS 20.03 there is a Gitea version 1.12.3. My machine has 1.9.6 installed. An upgrade from 1.9.X to 1.12.X works? Guaranteed?

@foxit64 I thought the following statement from earlier in this thread would make the situation very clear:

gitea 1.9.6 -> 1.10.0 introduces breaking changes: https://github.com/go-gitea/gitea/releases/tag/v1.10.0

So the answer is no, an upgrade from NixOS 19.03 to 20.03 will not "work" without sysadmin intervention. Users expect (or at least users should expect) that between major releases of NixOS they will need to read release notes and deal with any potential issues. The same is true for any distribution which makes releases.

@aanderse

So the answer is no, an upgrade from NixOS 19.03 to 20.03 will not "work" without sysadmin intervention. Users expect (or at least users should expect) that between major releases of NixOS they will need to read release notes and deal with any potential issues. The same is true for any distribution which makes releases.

At least to my understanding Gitea's use breaking changes might be a bit different from what has been asked here:
If you go through the list of breaking changes, it's mostly a change or deprecation of API or UI functions. So services depending on Giteas API might have to be adapted, and that's ok.
But what @foxit64 might be asking for (and if they aren't than I do ask) ist the question of a working upgrade path: My experience from using Gitea on a non-NixOS system so far was that it handles database schema migrations or filesystem structure changes automatically if you continuously upgrade to the next version. But that might not be the case if you skip major-ish versions like going from 1.9.x to 1.11.x (which already has an RC out) might not work automatically. For eg. Nextcloud you are supposed not to skip versions.

The release notes don't say anything so we can either assume that implying everything's fine, or taking that as something to check before the next release.

But that might not be the case if you skip major-ish versions like going from 1.9.x to 1.11.x (which already has an RC out) might not work automatically.

Even that should usually work, it's just not tested and midght break something. But each version has all migrations for all past versions included.

Uff, this should be made sure to work in any case - you can't really control when people do upgrade gitea, and whether they do incremental upgrades or just bump to the latest version, especially if they use the package(s) provided by their distro.

@flokli We could add a test for that case, but from my experience it usually works and the only cases where it does not are edge cases and only affect a minority of users.