mkottman/acpi_call

New fork maintained by the NixOS community

Mic92 opened this issue Β· 21 comments

Mic92 commented

Since this repository is not maintained anymore, we
decided to adopt the maintenance.
Patches welcome!
https://github.com/nix-community/acpi_call

nckx commented

Hi @Mic92! Since issues on your fork are disabled I'm responding here.

There's already a similar maintained fork at https://github.com/teleshoes/acpi_call. Have you reached out to them at all? (They also disable issues, so... yeah.)

You already share the patches that actually matter. Consolidation saves effort and prevents confusion. I for one am not sure which horse to bet on and don't like that I have to.

Thanks (from an ex-Nixer)!

Mic92 commented

I activated the issue tracker on our repo.
@teleshoes do we want to join forces? I actually would prefer to keep it in nix-community since this also gives other people from the NixOS community to step in as required.

(oh snap, issue tracker was disabled on mine too. also not intentional, just never enabled it)

so, i would LOVE to hand this over. i only maintain it to maintain my other project, tpacpi-bat.

but i dunno, mine has been the defacto upstream for like 5 years now, and lots of people have forked my fork already and submitted pulls. i dont wanna mess with them by closing yet another copy of this repo. what do you think?

(oh snap, issue tracker was disabled on mine too. also not intentional, just never enabled it)

so, i would LOVE to hand this over. i only maintain it to maintain my other project, tpacpi-bat.

but i dunno, mine has been the defacto upstream for like 5 years now, and lots of people have forked my fork already and submitted pulls. i dont wanna mess with them by closing yet another copy of this repo. what do you think?

Looks like yours should be moved to over to NIX since they have no issues nor PRs yet on theirs. Github is good doing the redirects.

Mic92 commented

We could rename our repository and than move yours and let github handle the rest.

oh right, transfer-ownership is probably the right way to do this. (github will let users transparently fetch from the new location using the old url?)

one caveat: is the nixos fork planning to include nix-specific features that might break acpi_call in other distros?

Mic92 commented

oh right, transfer-ownership is probably the right way to do this. (github will let users transparently fetch from the new location using the old url?)

Yes github will keep the old clone urls intact but send a message to users that the location has changed.

one caveat: is the nixos fork planning to include nix-specific features that might break acpi_call in other distros?

No. If we ever need this, those patches will be applied in nixpkgs.

ok awesome, works for me!

(hmm, why rename? wont we still then just have 2 competing forks? just delete it from github, transfer mine, then cherry-pick your 2 patches into the newly nix-owned repo.)

Mic92 commented

My idea, was:

  1. Rename ours
  2. Move yours
  3. Delete ours

We have users pulling the source, so I did not want to break the url in between.

mm, cant do that tho, because the destination owner cannot have any forks in the same fork-network

EDIT: i think the above is true, but i dont know from experience

Mic92 commented

Mhm. ok. Maybe I move it back to my own github user instead.

ok, ill push the button and see if it works

nix-community already has a repository in the mkottman/acpi_call network and You don’t have the permission to create public repositories on nix-community

Mic92 commented

Ok. I move it to my own user than.

gotta delete acpi_call-legacy, and add me to the organization with repo-creating powers

Mic92 commented

Move is done. I add you to the organization.

Mic92 commented

You should have an invite.

woo! transferred, seamless redirect works now. thanks!

Mic92 commented

Thanks. I give you access to the repository as well.

nckx commented

Wow. That was fast. Thank you both! πŸ˜ƒ