[xmonad] xmonad{,-contrib} on github

[Michael Sloan]

> From: Carsten Mattner <carstenmattner at gmail.com>
> Date: Sun, Aug 26, 2012 at 3:18 AM
> It promotes sloppy quick patches and committing to master and not learning
> to use git properly resulting in multiple pull request for the same patch
> until they get it or if they don't waste of the pull request counter
> (integer). If used properly a branch linked to a code review with comments
> system is not bad and can be useful, I don't disagree with that.
>
> I've also quite often seen projects with commits that didn't have proper
> and useful commit author info at all. This is something which darcs
> insists on setting up but git is less strict about and will happily accept
> author info which is not useful outside the commit author's local machine
> realm.
>
> To be safe I have to doubt the quality of a patch if the contributor
> cannot be bothered to learn use the vcs properly.

Fair points, although some spend more time on their code / theory /
research than their tooling.  Not everyone that can make valuable
contributions is a savvy developer.  It does indicate that the patch
should be given thorough scrutiny, though, certainly.

At least when using pull requests you will be able to figure out where
the patch came from and at least associate it with a github user.

>> Here's a concrete example of the benefits of some degree of centralization:
>>
>> Today, I tried to rebuild all of my favorite Haskell projects using
>> GHC 7.6.  Whenever I ran into errors while cabal-installing, I'd
>> immediately google "github haskell $PKG", hope that one was there, and
>> take a look at the recent commits, pull requests, and what forks
>> exist.  For example:
>
> This is a common theme and should be supported by convention in tandem
> with metadata and optional flags on hackage so that it's easier to track
> in the package index.
>
> Another approach given Hackage would be a documented way to collect
> compile fixes and link to it from the package index while ideally also
> allowing to query from the command line.

Right, but actually getting people to follow and accept that
convention is a big process of social change, whereas people already
use github.  There's a lot of Haskell on github - the diagrams
project, for example, recently switched over from darcs, and that
really benefited discussions about changes and code review.  In the
short term, github is more effective, and it's getting better as time
goes on (of course)

>
>> Now that I'm looking to do the same with XMonad, I get more errors
>> (XMonad/Core.hs:34:25: Module `Prelude' does not export `catch'), but
>> I have no way to tell if anyone else has already fixed these things.
>> Minor stuff, sure, but I imagine someone's already done it, and it'd
>> be convenient to just clone their repository.  Of course, nothing is
>> fundamentally different from the darcs situation  - someone could have
>> sent out an email that would achieve the same.  But the point is, they
>> don't, because the barrier to entry is too high.  Github lowers this
>> barrier, encouraging more speculative commits, providing a way of
>> finding out what people are working on.
>
> What makes it lower? It's much easier to send an email than log into
> github and use their website which may be down. Sending the email to the
> maintainer and CC'ing the list is more reliable than using github. If you
> have properly configured darcs or git it's easy as 'darcs send'.

Well, often times sending a pull request does generate email.  The
potential for github being down is annoying, but this has never, in my
memory, effected my usage of the site in the past four years.  Maybe I
was lucky - but hackage outtages have effected my day-to-day
Haskelling far more.

I use hub, http://defunkt.io/hub/, pretty heavily.  It allows you to
do things like "hub diagrams/diagrams-core" to checkout repositories.
You fork using "hub fork", and can create pull requests using "hub
pull-request".

>> If anything, github promotes a healthier decentralized community,
>> because the forks are centrally tracked, more discoverable.  This can
>> increase the potential for collaboration and reduction of duplicated
>> work
>
> You don't gain much when all forks are on the same server and the index
> is also centralized.
>
> So, what I'm trying to say is that we shouldn't start giving into a
> single commercial entity for all of our open source collaboration.

Well, you still have your local forks.  If github goes down, your
project lives on, and you simply need to find a github replacement or
use the email approach.  The pull request information is persisted in
the form of the email trail, albeit somewhat less friendly.  This is
the advantage of DVCS (along with offline support) - centralizing DVCS
is not a contradiction - it's infact natural in order to reap the
benefits of both.

-Michael