[U-Boot] Mirror to github
Six people have various modifications to u-boot hosted on github. These projects aren't linked to each other.
I just talked to the github people. To fix this the main u-boot repo needs to be pushing a clone of itself to github. This is free to do, just make a git hub account and then set your repo to mirror changes there. Once the mirror is in place, github users can fork from from it. Now github can links these forks to the root repo and not keep six copies.
The linux kernel git tree is already being mirrored at github.
The effect of this is to create a public place where people can work on patches for u-boot.
Jon Smirl wrote:
Six people have various modifications to u-boot hosted on github. These projects aren't linked to each other.
I just talked to the github people. To fix this the main u-boot repo needs to be pushing a clone of itself to github. This is free to do, just make a git hub account and then set your repo to mirror changes there. Once the mirror is in place, github users can fork from from it. Now github can links these forks to the root repo and not keep six copies.
The linux kernel git tree is already being mirrored at github.
The effect of this is to create a public place where people can work on patches for u-boot.
Hi Jon,
This seems like a good idea to me but bears thinking about...
Just to reiterate some history, U-Boot was hosted on SourceForge for a long time, but SF became slower and slower. When it became intolerably slow, Wolfgang took the bits off and we transitioned to git, hosted on denx.de. This has worked *extremely* well. Even for people that are forking and not pushing (all of) their patches back, git has to be a HUGE win over trying to to the same thing with SVN. (At CIdeas we use to clone the SVN repository and then control local changes with RCS - bleah!)
It looks like github's business model is reminiscent of SF (and borrows from BitMover/BitKeeper too - pay to be private). It appears to be a lot less grandiose that SF - only doing git repo hosting, not the whole development lifecycle model (repo, bugtracking, web pages, etc.).
On the plus side ---------------- * It costs denx.de nothing to mirror the master to github
* It spreads the load (although denx.de seems to be responsive to date)
* Since git is *distributed*, github is just another repo and so we aren't "migrating onto" it and, if their business model fails, we wouldn't have to "migrate off" of it.
* It would encourage more public "private" repos - currently there are a lot of repos that are private or are publicly available but not advertised / not discoverable. This could be a Good Thing for cross pollination and getting wider testing and acceptance of patches before they get included into the mainline. Or not.
* Wolfgang already has the denx.de infrastructure set up, but this may give denx.de relief on the sysadmin work.
On the negative side -------------------- * Wolfgang would potentially give up some (mostly illusionary) control. * Brand dilution? Would people get confused which was master? Do we care?
Questions --------- * How stable is github? What is their long term viability? * Do we care? * Who is github? What is their relationship with EngineYard? * (EngineYard is pretty expensive host for a free service.) * (http://logicalawesome.com/ are the guys behind github.) * Do we care? * What questions haven't I asked?
Thanks, gvb
On Mon, Mar 16, 2009 at 9:44 PM, Jerry Van Baren gvb.uboot@gmail.com wrote:
Jon Smirl wrote:
Six people have various modifications to u-boot hosted on github. These projects aren't linked to each other.
I just talked to the github people. To fix this the main u-boot repo needs to be pushing a clone of itself to github. This is free to do, just make a git hub account and then set your repo to mirror changes there. Once the mirror is in place, github users can fork from from it. Now github can links these forks to the root repo and not keep six copies.
The linux kernel git tree is already being mirrored at github.
The effect of this is to create a public place where people can work on patches for u-boot.
Hi Jon,
This seems like a good idea to me but bears thinking about...
Just to reiterate some history, U-Boot was hosted on SourceForge for a long time, but SF became slower and slower. When it became intolerably slow, Wolfgang took the bits off and we transitioned to git, hosted on denx.de. This has worked *extremely* well. Even for people that are forking and not pushing (all of) their patches back, git has to be a HUGE win over trying to to the same thing with SVN. (At CIdeas we use to clone the SVN repository and then control local changes with RCS - bleah!)
There is no intention to move u-boot from it's current location or change the method of submitting patches, etc.
github would be an optional place for people to publicly store patchsets that for some reason aren't read for the main repo yet. In my case we have prototype hardware that has been given to a dozen people spread out all over the place. This is prototype hardware with parts non-functioning and buggy. It's not code you want added to the main u-boot repo. When correctly functioning production hardware is available I'll submit a set of clean patches to the main repo.
Meanwhile it is convenient to use a place like github. Log into github and make a fork from the master u-boot repo (just a mirror of the real one, that's the missing part). Now you have a publicly visible copy of the u-boot repo that you can write to. Push your patch set into it. Tell the other people to clone the denx u-boot repo then "git remote add github url-to-project", "git fetch github", "git checkout -b mybranch github/master". Now you have a copy of my patch set that I can keep rebasing to track the changes in the master u-boot repo.
stgit (http://www.procode.org/stgit/) is a very useful tool for maintaining patch stacks. You can individually apply and update the patches, email, etc. It is fully integrated with git. It is cool to "git fetch denx", "stg rebase denx/master" and my patch stack rebases. If there are conflict the rebase pauses and lets you fix things.
It looks like github's business model is reminiscent of SF (and borrows from BitMover/BitKeeper too - pay to be private). It appears to be a lot less grandiose that SF - only doing git repo hosting, not the whole development lifecycle model (repo, bugtracking, web pages, etc.).
On the plus side
It costs denx.de nothing to mirror the master to github
It spreads the load (although denx.de seems to be responsive to date)
Since git is *distributed*, github is just another repo and so we aren't
"migrating onto" it and, if their business model fails, we wouldn't have to "migrate off" of it.
- It would encourage more public "private" repos - currently there are a lot
of repos that are private or are publicly available but not advertised / not discoverable. This could be a Good Thing for cross pollination and getting wider testing and acceptance of patches before they get included into the mainline. Or not.
- Wolfgang already has the denx.de infrastructure set up, but this may give
denx.de relief on the sysadmin work.
On the negative side
- Wolfgang would potentially give up some (mostly illusionary) control.
- Brand dilution? Would people get confused which was master? Do we care?
Questions
- How stable is github? What is their long term viability?
* Do we care?
- Who is github? What is their relationship with EngineYard?
* (EngineYard is pretty expensive host for a free service.) * (http://logicalawesome.com/ are the guys behind github.) * Do we care?
- What questions haven't I asked?
Thanks, gvb
Dear Jerry Van Baren,
as usual, you are asking a lot of very interesting and important questions.
The situation is that I already discusses this matte with Jon at length in private mail, and I have made myu mind up I do not attempt to register at github.
In message 49BF008F.5090608@gmail.com you wrote:
On the plus side
- It costs denx.de nothing to mirror the master to github
This is not clear. It may be free at the moment. But did you read the Terms of Service? "Logical Awesome reserves the right to update and change the Terms of Service from time to time without notice. ... Continued use of the Service after any such changes shall constitute your consent to such changes." That means that you they can change the terms from "free" to "$$$" any time they like, without even noticing you - you will just receive a bunch of invoices and have to pay them, because you agreed to these terms, and to the changes by continuing to use github (as you didn't even have a chance to learn about the changes).
- It spreads the load (although denx.de seems to be responsive to date)
We can cope with the load, I think.
- What questions haven't I asked?
Why should we support github? It is them who want to save storage space by having a local "master" repository. What prevents them to create one? If they want, they can clone it from git.denx.de - they don't need our help for that. They can also keep it up to date easily, either through a simple cron job that periodically pulls from us, or by registering to the rss feed and reaction on that or ...
I see no reason to support them, and I see lots of reasons not to accept their terms of service.
Best regards,
Wolfgang Denk
participants (3)
-
Jerry Van Baren -
Jon Smirl -
Wolfgang Denk