Update links about nuklear

[Nielsbishere]

But couldn't you have left the old files there and updated the readme to point to the new repo? If people didn't copy the header themselves it would break if they get latest on the submodule

[englercj]

We deliberately did not fork anything, but stopped knitting the old chord and started from that point at a different place.

That is the definition of a fork. The author left, and you continued development elsewhere. That is a fork. You made a fork here manually, you just didn't let GitHub link back to the original repository.

Forking means just making a new remote branch, but that would mean few dudes are trying to do things their way, which is not true at all - we just want to continue.

That's not what a fork is. A fork doesn't imply a "few dudes are trying to do things their way". It just means this repo continues elsewhere outside the original one, with the original link maintained for historical purposes.

The only logistical reason not to do a real fork would be the GitHub search mechanics. Not optics.

Btw. did it even appear to you it's impossible to fork a repository as an organization?

You can definitely fork a repo into an org. I've done it myself, and it is mentioned in the docs:

You can fork any public repository to your user account or any organization in which you have repository creation permissions. For more information, see "Permission levels for an organization."

Also, just because it is bothering me: Fail Fast refers to a situation in which if there is a problem, you should fail early so it is visible. This situation doesn't really fall into that category. The submodules to the old repo would've continued to work fine. My web links to the code files would've continued to work fine. There was no problem. You created a new problem to catch people's attention so they moved to the new remote, even when they didn't need to. That was unnecessary.

No need to get emotional or think off some takeover fairy tales - it's plain rational choice.

No need to get so defensive about some well intentioned advice. Deleting the code and starting a new repository of the same name certainly has the image that you were just taking the code and erasing the history of where it came from.

There is a reason there are multiple people on this page asking these questions. It looks weird, and it didn't feel very respectful of the normal OSS process projects go through. This isn't a couple people "getting emotional" or "thinking of some takeover fairy tales". Just a few people trying to understand what is happening, and offer advice to someone who may not have done this kind of thing before.

[the-grue]

Ignoring the insults and negativity.

Thanks @vurtun for archiving your original repo and making the files visible again.

Carry on folks and best of luck!

[Nielsbishere]

Solved in PR #10, using GitHub CI instead.

[dumblob]

Yeah, correct. PRs are welcome (I'm still short of time 😢).

[englercj]

Is there a reason the repo wasn't moved so that github will redirect all the old URLs automatically?

[dumblob]

@englercj unfortunately there is a reason

[englercj]

that is unfortunate :/

[the-grue]

Wouldn't it have been better to archive the original repo instead of deleting all the files? Almost seems like an attempt to rewrite history...

[dumblob]

Wouldn't it have been better to archive the original repo instead of deleting all the files?

Nobody has the permissions to do so. Only @vurtun has them (since it's his personal repository), but he is inactive for several years now. See also the request to @vurtun from me (as I'm the only one having contribution permissions in his personal repository, but I have no admin rights 😢).

Almost seems like an attempt to rewrite history...

Not sure what you mean. This new repository keeps the whole git history and I see no signs of "history rewriting" (might be related).

[dumblob]

But couldn't you have left the old files there and updated the readme to point to the new repo? If people didn't copy the header themselves it would break if they get latest on the submodule

That's the plan (it's part of programming best practices).

[the-grue]

Not sure what you mean. This new repository keeps the whole git history and I see no signs of "history rewriting"

Yes, you kept the git history. But you didn't base this off a fork, for one thing, you abandoned all the issues and outstanding pull requests for another. Also, deleting all of the files from the original author's repo makes this seem more like a hostile takeover than a "we want to go in our own direction because the original author is no longer available".

It just doesn't sit well with me and I would imagine I am not alone. I discovered and forked the original repo a couple weeks ago and before I got a chance to do anything with it I see all the files are gone and now there is this site. I understand what you are trying to do, I just disagree with the way you are going about it in respect to @vurtun 's repo.

I would just like to recommend that you reset @vurtun 's repo back to the October 1, 2019 commit (adc52d7), update the readme file to point to this site, and move on.

[dumblob]

@the-grue it seems we're talking at cross purposes. @vurtun said, that he has no more time to maintain his repository few years ago. He gave me (and maybe also someone else who was also inactive for years) contribution permission to his repository. His repository can't be any more the project main repository (can't scale), so we moved the project elsewhere.

We deliberately did not fork anything, but stopped knitting the old chord and started from that point at a different place. Forking means just making a new remote branch, but that would mean few dudes are trying to do things their way, which is not true at all - we just want to continue. Btw. did it even appear to you it's impossible to fork a repository as an organization?

1. The best option would be to use the GitHubs functionality to move the repo.
2. The second best option is to follow best practices.

The option (1) wasn't available, so we went with (2). No need to get emotional or think off some takeover fairy tales - it's plain rational choice.

Btw. now the repo https://github.com/vurtun/nuklear is archived (thanks @vurtun!) and has some content.

---

If it's difficult for you to change remote branch in your already cloned repository or whatever, then tell us and you'll get some help. It's though dead easy under usual conditions, so I assume that wasn't the reason for this discussion.

[dumblob]

That is the definition of a fork. The author left, and you continued development elsewhere. That is a fork. You made a fork here manually, you just didn't let GitHub link back to the original repository.

I must disagree here. There is at least 100 authors (and they spent together more time with Nuklear than @vurtun). So not a fork at all. Just permission issue.

The only logistical reason not to do a real fork would be the GitHub search mechanics. Not optics.

Disregarding search mechanics, the risk is very high, that a non-archived repo will make everybody using any automation tooling to stick with the original unmainted repo. Nobody knew when - and if so - @vurtun will appear again and archive the original repo after those years of inactivity. You can't let users think that their automation tools fetch the newest master if they won't. The smart users fetching a particular commit are unaffected. There is no harm done. Please don't try to pretend otherwise.

You can definitely fork a repo into an org. I've done it myself, and it is mentioned in the docs:
...

Please enlighten me how - it's just mentioned in docs but without telling how to do that (and no, hub doesn't count as a solution here as noone can follow all the new capabilities of every single existing app in the world nor follow all changes to GitHub API).

Deleting the code and starting a new repository of the same name certainly has the image that you were just taking the code and erasing the history of where it came from.

First and foremost - nobody erased any history. It's all there and will stay there. Second, anyone knowing Nuklear history wouldn't have had any such thoughts, so I must consider this discussion a plain misunderstanding and lack of (historical) information.

Just a few people trying to understand what is happening, and offer advice to someone who may not have done this kind of thing before.

That's why I'm trying to meticulously explain every detail and didn't just say "it's how it is" (and closing and locking the discussion or whatever). It costs me a lot of time (and it's by far not the first move from a stagnating private development to an organizational structure I've organized in my life), but I still believe, you all will one day (hopefully soon) become very valuable contributors to Nuklear and immediate mode UIs in general.