Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It looks like it was actually forked by someone on GitHub with the username cyphar, and stgraber merely has a clone on his GitHub account, which of course is common for anyone who contributes to any project.

For example, the README.md links to cyphar's repository, not stgraber's, and this page says it was forked from cyphar's repository.

The existence of this page merely suggests that stgraber is contributing, or intends to contribute, to the fork. Not that he forked it himself.

Perhaps he did fork it, or does intend to be involved in maintaining this fork, but I think the editorialized HN headline "forked by former project leader" is highly misleading unless there's actually something that demonstrates that stgraber is intending to run a fork, and this page isn't it.



> It looks like it was actually forked by someone on GitHub with the username cyphar

Interestingly, cyphar appears to be a SUSE employee.


That does indeed appear to be the case. :P


Does that mean SUSE will likely be using your fork from here on? :)


We don't ship LXD in SLES, I'm the package maintainer for LXD on openSUSE (though this does mean you get access to it in SLES through the PackageHub). I am not yet sure how I want to tackle the migration issue, and obviously I have my hands full with other things at the moment :D.

We will be making some cli-related changes that would make "alias lxd=inc" not work, so I suspect we will need to package incus separately and provide a mechanism to migrate. But nothing is set in stone quite yet. But once incus is ready to start being packaged, I will package it for openSUSE (and possibly come up with a multi-package setup using the Open Build Service to build and host all of the packages in one place).


Having said that, there are a pile of issues at https://github.com/cyphar/incus/issues that all look like high level project-type decisions that are filed by stgraber.


stgraber made a bunch of commits on this fork already.


having a “clone of a fork of what you originally made” is almost more interesting.

the fork is already one hoop more than should be needed, so this adds one for an unknown reason. cloning doesn’t even indicate intent to contribute - just desire to have a copy of code for yourself. which, it’s his code, so, why…


Tell me you don't contribute to OSS without telling me you don't contribute to OSS :))

Clone of a fork is necessary to open PRs when you don't have the permission to contribute to the main repository.


[flagged]


There was no judgement in my statement, just a simple joke, because everyone who contributes to OSS must make their own local fork for the reason I specified (and this is inherently utterly baffling and confusing to newcomers, who often barely grasp branches)


Tell me you don't read everything without telling me you don't read everything. That doesn't answer why he would clone a fork of his project and not just contribute to the main project


Because the project got taken over by Canonical. The README states why it was forked, and contributing to a community-led version of a project swallowed by a commercial entity makes a lot of sense to me.


what’s interesting is just that, the big name is contributing. not leading. at least not officially. at least not yet.

this is a signal, an unusual one worthy of hn.


Because they don’t want their repo cluttered with PR branches. It’s maybe not obvious, but in a public project anyone could branch and submit a PR which leads to a mess. This is how it’s done in many large companies as well, not just OSS. It saves you from scratching your head wondering if deleting this year old feature branch is actually throwing good work out. The news is that this person is working on the project, this clone is evidence of that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: