Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[19.09] gitea: 1.9.6 -> 1.10.1 #73741

Open
wants to merge 2 commits into
base: release-19.09
from
Open

Conversation

@etu
Copy link
Contributor

etu commented Nov 19, 2019

Motivation for this change

(cherry picked from commit 8d5a0e1)

Follow up on #73415 and #73416.

Backport by request from maintainer @kolaente.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.
Notify maintainers

cc @

(cherry picked from commit 8d5a0e1)
@etu etu requested a review from kolaente Nov 19, 2019
@etu

This comment has been minimized.

Copy link
Contributor Author

etu commented Nov 19, 2019

@GrahamcOfBorg test gitea

Copy link
Contributor

tomfitzhenry left a comment

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

Does NixOS's stable track offer any guarantees on not introducing breaking changes?

@etu

This comment has been minimized.

Copy link
Contributor Author

etu commented Nov 19, 2019

@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.

@aanderse

This comment has been minimized.

Copy link
Contributor

aanderse commented Nov 19, 2019

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.

@kolaente

This comment has been minimized.

Copy link
Contributor

kolaente commented Nov 20, 2019

@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.

@dR3b

This comment has been minimized.

Copy link

dR3b commented Nov 27, 2019

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.

@FRidh

This comment has been minimized.

Copy link
Member

FRidh commented Dec 1, 2019

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.

@kolaente

This comment has been minimized.

Copy link
Contributor

kolaente commented Dec 5, 2019

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?

@aanderse

This comment has been minimized.

Copy link
Contributor

aanderse commented Dec 5, 2019

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... 🤷‍♂

@flokli

This comment has been minimized.

Copy link
Contributor

flokli commented Dec 5, 2019

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?

(cherry picked from commit c2682a0)
@etu etu changed the title [19.09] gitea: 1.9.6 -> 1.10.0 [19.09] gitea: 1.9.6 -> 1.10.1 Dec 6, 2019
@etu

This comment has been minimized.

Copy link
Contributor Author

etu commented Dec 6, 2019

@flokli No problem and done! :)

@GrahamcOfBorg test gitea

@FRidh

This comment has been minimized.

Copy link
Member

FRidh commented Dec 6, 2019

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.

@FRidh

This comment has been minimized.

Copy link
Member

FRidh commented Dec 6, 2019

Regarding gitlab updates on stable #74978

@flokli

This comment has been minimized.

Copy link
Contributor

flokli commented Dec 6, 2019

@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.

@foxit64

This comment has been minimized.

Copy link

foxit64 commented Jan 9, 2020

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?

@aanderse

This comment has been minimized.

Copy link
Contributor

aanderse commented Jan 9, 2020

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?

@foxit64

This comment has been minimized.

Copy link

foxit64 commented Jan 9, 2020

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?

@aanderse

This comment has been minimized.

Copy link
Contributor

aanderse commented Jan 9, 2020

@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.

@schmittlauch

This comment has been minimized.

Copy link
Contributor

schmittlauch commented Jan 12, 2020

@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.

@kolaente

This comment has been minimized.

Copy link
Contributor

kolaente commented Jan 12, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.