GitHub

[Jeff Mitchell]

Magnus Bergmark wrote:
> Oh, I though you guys used a traditional centralized model with SVN. My
> bad. Usually that is something that can be safely assumed with regards
> to OpenSource and SVN. :-)

Yes, which is why one-shot developers do not get commit access.  It's
public to read, not to write.

>     > I still doesn't understand what you are trying to say here. All
>     branches
>     > in the public repo is visible in your local clone.
> 
>     That's because you're thinking of the rails repo, whereas my example is
>     the "normal" github method, where everyone has their own account and
>     forks off the main repo.  If you look at it in that context it will
>     probably make sense, and it's why the everyone-shares-one-account model
>     is the only usable way for any decent sized project on Github.
> 
> 
> How would multiple repos be easier on a non-GitHub host? I'm pretty sure

No one said anything about multiple repos on a non Github host.  What I
did say is that the common Github-promoted model of people forking off
projects and working on their own repo would be a difficult workflow for
us.  If we didn't use Github, we'd just have one repo (and even if we do
use Github, we should just share one account and have one repo).

(Actually, I think "fork" is a bad term for them to be using, since it's
both disingenuous and encourages the wrong mentality.  Forking off
established projects is not something that is done that often, and
usually for good reason...better to pool developer resources than to
fraction them.  Plus, the workflow that generally happens isn't so much
a fork as a clone, which is the term I'd prefer that they use (and a
"git clone", plus some scripting foo, is exactly what they are doing
under the hood anyways.  But that's neither here nor there.)

>     Umm...or you can just have people send it in with format-patch.  No need
>     to overly complicate things for a spelling fix.  In fact, the above
>     method is overly complicated for users as well as developers.  Much
>     easier to simply have them clone the public repo, make their change, and
>     use format-patch to send in the change.
> 
> 
> Yes, that is correct. format-patch is obviously a better choice here.
> Still, the UI on GitHub handles this even more easy IMHO, and one method
> does not remove the possibility of using the other.

It comes down to personal preference as to which people prefer.

> True. Taking user training into consideration is also important. Newbies
> may forget to update their repository before sending the pull request
> and this might introduce some overhead. 

Right...they'd have to remember to pull from their upstream tracking
branch, merge into their copy, push up to their repo, and then send the
pull request (to minimize issues on our end).  The workflow of "I have a
repository of my own, but I only ever write to it, and do my reading
from elsewhere" is difficult for some people to grasp.

That's why I think format-patch can be a bit easier for newbies...you
don't have to go through the mind tricks of learning how to do it the
GitHub-specific way so that you are always up-to-date when you send pull
requests.  You can just worry about pulling from your clone of the main
Amarok repo.  But again, it will come down to personal preference.

> I heard that Git hosting over HTTP was something you didn't want (http <
> git < ssh), but I'm ignorant about that.

Using HTTP or HTTPS goes through HTTP proxies.  Useful for getting code
into and out of corporate environments (which is how I've used it for
some non-Amarok code that I needed).  It's definitely got its share of
bugs, though.

> I can say this: I think moving to GitHub is not in your interests
> anymore

I don't think it ever was  :-)  (Not GitHub specifically, but moving the
project fully to Git at the current time.)  Because...

> since you still need to sync with svn regurarly

Yes, this will make too many headaches if we try to move the project to
git (instead of random branches people work on).  We've already had
experience with what a headache this can be.

> and AFACT from
> the scm mailing list, the plans to move KDE to Git is moving along.

Ahh, nice.  I hadn't heard that...last I had heard it was stalled.

> You
> should probably just use the solution they will be using (which is
> self-hosted Gitorious, if I recall correctly) when the time comes and
> you don't have to sync to svn anymore.

Right.  When we get off SVN I don't have any issues moving to GitHub (so
long as we all share an account), but I don't think it will be possible
anyways because of the translators, etc. (the same reasons that keep us
on the KDE SVN now).  I think we'll end up going to the KDE Git
solution.  (The reason it's not GitHub, btw., even though they have the
infrastructure, is that GitHub is closed-source.)

--Jeff