kubecolor: 0.0.21 -> 0.0.25, switch back to upstream, cleanup maintai…

[SuperSandro2000]

…ners

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[emilylange]

@SuperSandro2000: a few things. Would be cool if you could respond :)

1. What was your motivation behind removing @ivankovnatsky from meta.maintainers? Did you two talk in private or something?
2. To me, it feels like the fork at https://github.com/kubecolor/kubecolor should still be preferred over https://github.com/hidetatz/kubecolor. Considering the diffs between those and comparing the responsiveness and k8s-wide community involvement of each maintainer. kubecolor/kubecolor@v0.0.20...v0.0.21 vs hidetatz/kubecolor@v0.0.20...v0.0.25, is any maintainer alive in this project ? hidetatz/kubecolor#95
3. What made you wanting to switch back to, what you refer to as, "upstream"?
4. Please keep meta.{homepage,changelog} in sync.

[ivankovnatsky]

I don't mind, except for the homepage and changelog update.

[SuperSandro2000]

What was your motivation behind removing ivankovnatsky from meta.maintainers? Did you two talk in private or something?

I sometimes remove not so active looking maintainers to so that a package does not look more active maintained then it really is. In the end I'd rather have one active maintainer on a package instead of 3 inactive.

To me, it feels like the fork at kubecolor/kubecolor should still be preferred over hidetatz/kubecolor. Considering the diffs between those and comparing the responsiveness and k8s-wide community involvement of each maintainer. kubecolor/[email protected] vs hidetatz/[email protected],

If you take a close look at the diff, then you see that kubecolor/kubecolor has not any significant changes, they mostly changed the import path and also the readme, ci and one code change. Compared to the original which had some more major changes.

[emilylange]

If you take a close look at the diff, then you see that kubecolor/kubecolor has not any significant changes, they mostly changed the import path and also the readme, ci and one code change. Compared to the original which had some more major changes.

I feel like there is a chance you might have confused kubecolor/kubecolor with hidetatz/kubecolor.

I would argue, kubecolor/kubecolor has more "significant" changes.
While

they mostly changed the import path and also the readme, ci and one code change

applies to hidetatz/kubecolor 👀

[SuperSandro2000]

I would argue, kubecolor/kubecolor has more "significant" changes.

I compared them again and the only relevant change is kubecolor/kubecolor@f5983ea#diff-58f406e38e3da16176434f1366d55aeeb357db33dec0d28a6e96714d80c50e77 and kubecolor/kubecolor@f5983ea#diff-6fda8dfbacb16a290308a43224a4965a24238e2a09a7048b24b1d15a37c02d87 . Everything else is not really relevant to the nixpkgs packaging.