[U-Boot] Mirror to github

[Jon Smirl]

On Mon, Mar 16, 2009 at 9:44 PM, Jerry Van Baren <gvb.uboot at 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
>



-- 
Jon Smirl
jonsmirl at gmail.com