Re: Switching from Subversion to Git

[Per Bothner <per at bothner dot com>]

Thanks for your strong reasoning - sorry I've been tardy replying.

On 09/05/2014 09:58 AM, Matthieu Vachon wrote:
> For me, it's more about switching to GitHub than to git. Switching to
> git (or mercurial) only would bring not much overall to the current
> process. The big advantages would come when switching to a hosted
> collaboration platform. GitHub being the preferred for many peoples,
> including me.
>
> Here some advantages I see in switching to GitHub:
>
> 1. Better collaboration
>
> GitHub is built around collaboration and is very good at it in my
> opinion. The way Pull Requests works as many advantages, being able to
> review and comment patches at a single place, putting together all the
> necessary information of changes. Being close to the source code is
> also a good plus being able to quickly point people to some part of
> the source code. Also, issues management is a good plus since their
> system is very clean and well made. Finally, not that important but
> being markdown-aware everywhere make it something I like to work with.

> Also, merging stuff into the main repository would require much less
> work from you. People do pull requests, you review them, they make the
> necessary changes and when ready, you only have to press a button and
> the merge is made. This requires less manual work on your side giving
> you more time for core development. There is not much patches right
> now, so it might be a non-argument, but still :)

Suppose we enable this workflow, how would that change my current
workflow for changes that I make?  Right now, after I've tested a
patch, I just do 'svn ci'.  With "raw git" (or Mercurial) its
two commands, which is not noticably worse.  But if I have a trivial
fix I want to make, what is my workflow when using github?

> Using issues and labels efficiently, people could easily know some
> easy pick to improve Kawa. This is a great way to get people to work
> and to plan future additions.
>
> 2. Git (would also apply for Mercurial)
>
> In general, I think git is far better and much pleasant to work with
> than SVN. This is mainly a personal opinion, but I feel I'm not alone
> thinking this. The branching model is damn good and fast and I always
> enjoy working with it. In find nowadays that tooling is getting better
> on git side than on SVN side. The fact that down time has much less
> impact on git than SVN is also a good point for me.
>
> Plus, I already worked on the SVN to git conversion. I maintain it on
> GitHub and syncing it with SVN from time to time. This would reduce
> the work needed to make the conversion.
>
> 3. Continuous integration
>
> Travis CI being tied to Github, just this piece would be a good
> improvement for a project like Kawa. Being able to test multiple
> platforms after each push to the repository is enormous considering
> the variety of Java implementation out there and versions supported
> by Kawa. Moreover, pull requests could be directly tested prior being
> merged in the master branch resulting in increased quality.
>
> Again, I have made some work on this regarding Travis and Kawa code,
> there would be not much work needed to activate this.

This could certainly be a big plus.

> 4. Better Feeling
>
> Savannah and al is a good platform, but GitHub feels much better than
> it. Most operations are web-based often resulting in less manual
> operations. The UI is nicer and it gives a nice feeling for new people
> to collaborate on the project. In my opinion, it is a more modern
> platform, continuously updated and always offering more and more
> features.

Kawa is a GNU project (though a low-profile one), and politically I
want to be part of the GNU umbrella.  That is one advantage to Savannah.


> 5. Exposure
>
> As other mentioned already, and I also agree with them, their would be
> more exposure possibility being on GitHub. There is a lot of
> developers on this platform and I'm sure it would bring collaborators
> in the future. I feel there is a massive amount of developer lurking
> on GitHub. It would also make a good blog post maybe attracting some
> traffic around the Kawa project.

That's not clear to be.  With millions of Github projects, I'd be
surprised if getting noticed would be any easier.

> 6. Organization
>
> A Kawa organization could be created on GitHub and more projects could
> be hosted their. For example, the current (or a new) Kawa website
> source repository could go their. This is something I would like to
> improve in the future. At some point, documentation could be hosted
> their also but that is another story.

For now I'd like to keep at least the Kawa web pages on gnu.org, and
use the existing framework.  (Not to deny that the webpages need work -
to start the home page needs to be simplified and the Features page
needs to be updated and punchier.)

I do own the kawa-lang.org domain.  If at some point we move the website,
I'd like to use that.

> The Kawa organization could also hosted some useful Kawa libraries
> their giving them more exposure and usefulness. Here at work, we have
> a bunch of useful of general Kawa modules that could be open-sourced.
> These modules don't belongs to Kawa core but could help adoption of
> Kawa by promoting re-usable common piece of software, something a la
> Guava.

> 7. Releases
>
> GitHub has a nice support for project releases tied to git tags. Kawa
> releases could be hosted on GitHub. Everything would be in one place.
>
> https://github.com/blog/1547-release-your-software

Kawa source tarballs are a bit more complex, following GNU standards.
Can the Github release mechanism handle that?  I see you can add extra
"assets" (such as pre-generated files), but it's not clear how to do
that automatically .

> 8. GitHub Pages & Wiki
>
> GitHub pages could be used to host a new website for Kawa. Based on
> Jekyll 2.0, a static site generator, the GitHub pages act solely as a
> hosting point. This reduce the burden of maintenance. I never used it
> myself, but releasing an minor update to a website is performed using
> a single push to a git repository, again reducing to a really
> low-level the maintenance of a website. Change, commit and push.
>
> https://pages.github.com/
>
> Moreover, all GitHub repository comes with a Wiki, enabling people to
> put their their own tip and tricks and cookbooks for using Kawa and
> stuff like this. Maybe not much gain but could be useful.
>
> In the end, there is potentially some disadvantages in switching to
> GitHub. But they should be minor and I don't see how they could
> overcome the advantages.

I have no experience using GitHub (except some simple browsing) so
we'd need volunteer(s) to do it.

If we switch to GitHub for bug-tracking (which I assume you wuld recommend?)
then we have problem what to do with existing issues.  I assume it would
be too difficult to migrate the existing issues.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/