Re: Is a move to github in order??

[Ivan Vučica]

tl;dr: Given some of the arguments below, GitHub, but primarily because of infrastructure. But with a plan on how to extract our data in case we want to move.

On Mon, May 26, 2014 at 11:24 AM, David Chisnall <theraven@sucs.org> wrote:

On 26 May 2014, at 00:54, Ivan Vučica <ivucica@gmail.com> wrote:

> (Pet peeve: GitHub is too often mentioned when Git itself is what's necessary.)

In my estimation, GitHub is what makes git attractive.  Git itself has numerous irritations, but the tight integration of everything on GitHub is very nice.  I'm now using it pretty much exclusively for hosting my projects.

BitBucket works nicely too.

Rhodecode is neat for selfhosting.

Gerrit is cool for codereviews.

(For personal use, BitBucket is particularly neat, as it allows a user to share private repos with up to 4 additional people. And if one wants to play sysadmin for yet another service, then Rhodecode is really nice.)

GitHub is an excellent offering, but it should not be mistaken for THE Git hosting service, and treated as the one and only player in town.

> Further comments to Gregory's original post:
> 0. GitHub has Mercurial support? If so, schweet. But maybe you're referring to hg-git on the client end?

You can check out / clone a GitHub repo using git, hg, or svn.  Just copy the URL it gives you and pass it to the client.  The server handles all of the translation.

This did not work:

hg clone https://github.com/ivucica/linux

SVN checkout does work. 

I presume the mention of Mercurial support relates to the fact that GitHub people worked on hg-git which is client-side and occasionally pretty flaky. I see no evidence of server-side support.

Can you point me to a demo repository that I can clone from GitHub, using Mercurial, without client-side changes?

> 1. That's a good reason to have a mirror there and possibly to accept patches through there... not necessarily for it to "officially" live there.

Doing this requires two-way sync, and git is really bad at this - it divides the world into upstreams and downstreams and doesn't like it when you have both roles.

I don't see why. Both Git and Mercurial are pretty decentralized, unless one touches history, which is in itself inviting trouble unless done very, very sparingly.

I see no issue with a scenario where GitHub repository can be a mirror that people can create pull requests on, while a reviewer can pull the change into a local repository and integrate it into central upstream.

Inconvenience, yes. ("Oh my, I can't just do a single click to integrate the change.")

Issue, no.

 

> 2. Do we want to do it through GitHub? Let's think about this. Gerrit is nice for code review.

Part of the advantage of using GitHub is that you get all of this stuff for free. GNUstep is a small project, and having little bits of infrastructure hosted by random volunteers doesn't work well.  Étoilé used ReviewBoard for a bit, but then it broken and Nicolas didn't have time to fix it.  The result?  No code review tool for a few years.

As long as it's one individual we agree upon, there isn't a problem; right now, I personally have on idea who is ultimately responsible for the website, who is responsible for code hosting, who is responsible for the domain, etc.

We have no contact points and in case something goes down, we're screwed. And if I want to make a change to the website, frankly, I have no idea where to turn to. Not just that: we have a wiki, we have a website, we have documentation pages, we have privately written, personally hosted tutorials randomly thrown around the web. It's a mess. In an ideal world, we would not point people to the wiki if we have a website: we'd look at the wiki and update the website. Or we'd point them to documentation.

This should be discussed separately, though, and not in this thread.

 

> 3. I don't think that giving GNUstep content to GitHub is a good idea.

Because?  We've moved all of Étoilé there and it's a lot nicer to work with than Svannah.

I'm not saying Savannah is nice or that we should stay there (frankly, I don't even bother touching Savannah).

I'm saying that locking GNUstep bugs etc inside GitHub may not be ideal.

GitHub is nice, but for example, BitBucket is lacking only a few features we may not even need. (I'm not advocating going to BitBucket.)

 

> 4. This is a major reason for going to Git and having at least a mirror on GitHub.

For FreeBSD, we have a GitHub mirror and it means that we lose most of the advantages of GitHub.  That's fine, because for FreeBSD we have a cluster admin team who are maintaining a few racks full of equipment for FreeBSD and can set up and run various things for us to give equivalent functionality.  This is not the case for GNUstep, however: the FreeBSD clusteradm team spends more time on cluster admin work than the current active GNUstep contributors spend on GNUstep in total.

Now this is a good reason.

I seriously don't think it's hard to fire up Git hosting, even with Rhodecode, and let it run. One especially doesn't need a whole cluster and a clusteradmin team to maintain it.

But nonetheless, having someone dedicated to maintaining the service would be nice.

As long as we can pull out data in case we want to.

 

That said, I don't think I should have too strong an opinion on this subject.  I've had little time for GNUstep recently and have increasingly little interest in Objective-C.  My last attempt to make a GUI application with GNUstep produced something that basically works, but was so much effort to get working that I'm seriously tempted to go and learn Qt and rewrite it.

I'm interested in the language and writing apps... but my contribution rate is known :-) and affected by various factors.

But moving to Git and having external contributors contribute more easily would help by getting more contributors.

--
Ivan Vučica - ivan@vucica.net