[U-Boot] Mirror to github

[U-Boot] Mirror to github

[Jon Smirl]

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
jonsmirl at gmail.com

[U-Boot] Mirror to github

[Jerry Van Baren]

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

[U-Boot] Mirror to github

[Jon Smirl]

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
>



-- 
Jon Smirl
jonsmirl at gmail.com

[U-Boot] Mirror to github

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Never put off until tomorrow what you can put off indefinitely.