8

I work at a small company in a small IT department. We use Visual Studio Online (the Team Foundation Server flavor of VSO) to store our source code. We're interested in deploying an open source (GPL v3) project for use here. The project is hosted on GitHub.

There are some bugs in the project however that we will need to fix in order to use it. We're happy to do so and I've been in contact with the project's maintainer, who seems receptive to pull requests.

My question is, what's the best way for us to create our own fork to maintain? I want to make sure it's easy to pull down new versions and submit Pull Requests back upstream. It's been suggested that we keep our fork in VSO, only as a Git repository, but I'm afraid that will make it harder to keep the flow of changes open. I was thinking that it would be better to create a GitHub org and keep our fork there. Is one of these approaches better than the other? If so, why?

Improve this question
0

2 Answers 2

Reset to default
6

I would suggest the following:

Fork the project on github. Having a fork on github is needed for much of its infrastructure around pull requests. Having a fork on github makes everyones life easier.

Optionally: Fork again to vso git. This way you can keep your in house development in house, and have all the issue tracking, CI, and other vso infrastructure all your other projects have as well.

Come release, you push from your repo to github, and pull request from there.

Improve this answer
2
  • 1
    Issue tracking.. I hadn't thought of that. Good call. This adds some overhead, but not much, so is probably the way to go.
    – RubberDuck
    Commented Sep 23, 2015 at 17:49
  • 1
    The overhead is pretty small (one additional git push and maybe some history re-writing/polishing) but the potential benefit, especially when you use the CI features, are pretty large
    – Martijn
    Commented Sep 23, 2015 at 17:55
5

I would suggest simply using GitHub. Its UI and paradigm is aimed specifically at what you want to achieve.

  • Presumably you are already fetching the original project directly from GitHub, so you have all the internal infrastructure established to continue to do so.
  • Simply forking it on GitHub maintains the link to the upstream original.
  • Having both your fork and the original on GitHub will facilitate pushing your changes upstream. The Pull Request mechanism simultaneously makes it easier for you to offer your changes, and for the maintainer to accept them.
  • Maintaining your fork on GitHub makes it very easy to meet the requirements (and spirit) of the GPL to publish all your changes, because it is published by default.
Improve this answer
6
  • 1
    I agree with you, but we'd be under no obligation to publish our changes unless we decide to redistribute the modified version. Good point though.
    – RubberDuck
    Commented Sep 23, 2015 at 14:01
  • Yeah, thought of that. That's why I added the "(and spirit)" bit
    – kdopen
    Commented Sep 23, 2015 at 14:02
  • 3
    So pay for a private account on github if you don't want to publish.
    – bmargulies
    Commented Sep 23, 2015 at 20:16
  • 1
    @bmargulies it's not a matter of wanting to publish or not. I was simply pointing out that we're not required to. Honestly, I don't appreciate the attitude. We're obviously looking to share our improvements on the project with the community. I was merely pointing out a (perceived) flaw in the answer.
    – RubberDuck
    Commented Sep 23, 2015 at 21:31
  • 1
    I couldn't think of a reason to mention the lack of obligation unless you were disinclined. I offered a practical option for an apparent practical problem. If you perceive attitude in that, you are probably mistaking me for someone who cares about free software ideology, which I do not.
    – bmargulies
    Commented Sep 24, 2015 at 2:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.