After a quick test, it is possible to attach an issue to your own fork of a repo. Here is what I did :
Fork a repo
Go to the Settings page of your fork.
Check the box next to Issues
You can now file issues on your own fork and they will not be placed in the main repo.
Releasing a project under the MIT license is giving people permission to fork the project. Part of the philosophy behind free software is to give users and developers the right to use, modify, and release the software in ways that wouldn't normally be allowed. If you don't want people to do this, then don't use the MIT license. You can't really complain when ...
As you mentioned in your question, people fork repositories when they want to make a change the code, because you
don't have write access to the original repository (unless you've been added as a collaborator by the owner of the repository).
In the forked repository they have write access and can push changes. They may even contribute
back to the original ...
The major difference between Gerrit's and GitHub's workflows are how changes are modeled.
In Gerrit, every commit is a change that stands on its own. Although Gerrit will show you the relationships between commits, reviews are performed on a per-commit basis. Teams that are good at breaking large changes down into small, self-contained commits are likely to ...
Was Xamarin's action and the way the action was done ethical or not?
Well, let's ask an expert - The Open Source Initiative's listing of the MIT License itself, with the license quoted in it's entirety:
The MIT License (MIT)
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and ...
In our line of work we tend to look for technical reasons, but in my opinion the primary reason isn't technical. If you look at GitHub Help or other GitHub tutorials, forking a repo is one of the major steps for how you "do" GitHub.
When people are learning and evaluating GitHub, just about every tutorial out there is going to tell them to fork a repo as ...
One possible reason: they have running code that depends on those projects and their build process involves pulling the dependencies from github. Having the fork protects them against breaking changes. For projects that don't tag versions, this is the easiest way to achieve that.
The entire point of Github is "social coding".
Personally, I fork repositories when:
I want to make a change.
I think the project is interesting and may want to use it in the future, but have no easier way of saving it for later on the device I'm currently using.
I want to use some or all of the code in that repository as a starting point for my own ...
I wouldn't call it unethical. I would call it unsportsmanlike. There's an unwritten expectation that you will give a good faith effort to improve the original version before deciding to fork, and it seems the original author feels that good faith effort wasn't made.
That being said, the best way to avoid your software being forked is to be responsive to ...
Make the fork, then make a branch immediately.
Now you have an "untouched" master that can be updated itself going forward to get the latest changes with git pulls.
Keep you branch local without pushing to remote and you can do rebases which will do the following for you:
save away your changes
apply the latest changes from master to your branch (the ones ...
There is also the option to transfer (ownership of) a repository from one account to another (e.g. from an ex-employee to an 'organization' account).
The "Transfer Ownership" button is at the bottom of the Settings page of the repository, in the "Danger Zone" section.
The current owner of the repository must have administrative privileges to the destination ...
The most effective way of protecting the name of your project is to register it as a trademark (and make clear in all documentation that the project name is a registered trademark), because then people are required to get your permission before re-using the name.
If you license your project under GPLv3, then you could also add the name-change as additional ...
License wise, unless you are making really major changes and have a really strong opinion on the license that you want to distribute those under, you should keep to the original license of the project you fork from. The code you copied must remain under that license anyway, so using a separate license for your changes is mostly a lot of additional hassle.
There is no consensus, and that is the spirit of git. Git very intentionally does not impose any sort of structure. In that way, it is really more of a version control framework than a complete system. People use git as a base to build whichever kind of structure works best for them. For some teams that's a format-patch workflow, for some it's github ...
To me it seems that you need two Repositories not two Branches. A branch is a mechanism to handle the changes within a single repository in order to eventually merge them with the rest of code.
If you really want to keep both versions of a Similar code-base in the same repository, then your only option is to go for a Branch, however as mentioned earlier, ...
Was Xamarin's action and the way the action was done ethical or not?
A lot of people are conflating the legal and ethical situation. The X11 license allows anyone to "use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so", so this is definitely legal....
You basically have it: once you create a fork, it's your own little sandbox.
I think the main thing that you need to do is immediately create a branch after you fork, in order to keep the original line of development separate from your own. Whether you develop in this branch or in master is largely a matter of personal taste. The one thing that would keep ...
What Xamarin did is legal and ethical... almost.
Let's have a look at the commit fixup of the license and misc typo fixes in the readme:
-Copyright (c) 2010-2012 cocos2d-x.org
-Copyright (c) 2008-2010 Ricardo Quesada
-Copyright (c) 2011 Zynga Inc.
-Copyright (c) 2011-2012 openxlive.com
-Copyright (c) 2012 Totally ...
This is exactly the reason why many large open source projects register their project name as a trademark.
This still allows anyone to use their code for an own project, but not under the same name. The Mozilla foundation, for example, has a trademark on "Firefox". That's why Debian ships with a browser called "Iceweasel" which is essentially Firefox.
Eric Raymond wrote a thoughtful piece about this at one time. The important point I think is
When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
Basically, will you offend them? It really depends on the them. What would be good to do is to contact the developer and ask what she or he would thinks ...
There are two paths you can take
You provide your modifications for inclusion in the original project.
You distribute your version as an alternative project.
The first option has the advantage that you won't be competing with each other and that you can share the maintenance effort. On the other hand, if the copyright of the original is held by one person/...
It's great that you want to keep the license the same: that makes things easier. As far as copyright holders are concerned: you can add to the list of copyright holders, but do not remove any names from the list.
This changes (I believe) if at some point in the future you have removed all contributions from one of the holders: at that point you could remove ...
Uncontrolled forking is definitely an anti-pattern. As you have discovered, it is relatively easy to consume all available resources, and then continue to consume them to the point where everything grinds to a complete standstill.
Just ask the Sorcerer's apprentice.
Like any problem involving recursion, you have to clearly understand your terminating ...
Cloning the repo to the developer's local machine is already a kind of forking. If each developer forks the repo on GitHub, this only serves to publish their current state of work.
This can be appropriate when there is a central master repo, and many contributors that are not trusted with direct access to that repo. This works great for open-source projects ...
Now that I'm updating/maintaining what is effectively a new version, how do I correctly give attribution to the original author?
Here's something I often see in similar situations:
Copyright 2016 - Project101, written by ndtreviv, based on Project100, originally written by RandomDude24
Replace links to the github.io page for the original project to my ...
Fork away and do your worst / best.
Open source software has always been about letting individuals adapt, change and challenge convention. The hard part about forking a project is developing a new community around you that believes in what you are doing.
For example I could download the source for Apache, make a few modifications and call it the next big ...
Your fork is simply a branch which will be never re-merged into the main trunk. I guess the maintainers of the project don't know about your branch and will never pay any attention to the changes you made to the original code base. So if you change parts of the original code where the maintainers apply also apply changes in the future, expect getting merge ...
Regardless of the use of your scenario, here is how you can do it:
master is exactly of the version the upstream master has
custom is your own "master" branch in which you have applied the formatting changes
all feature branches are branched off custom if you don't want them to be pulled into upstream master
Once master is updated, you rebase custom to ...
The answer to the question "should I clone or fork" is exactly the same as the answer to this question "do I want my own personal version of this project?" yes = fork, no = clone the repository.
In git, branch is a light weight thing that is often temporary and may be deleted. A fork (on github) is a new project that is based on a previous project. You ...
I would have gone the other way - instead of making the common parts a reusable library, you should implement a plugins architecture and create plugins for the different types of saloons.
You'll have the main application code, which includes the common codebase and some infrastructure for the plugins(e.g. interfaces to be implemented in the plugins), and ...