[xmonad] xmonad{,-contrib} on github

[Michael Sloan]

Once again, meant to send the email that this is a response to, to the
full list.


---------- Forwarded message ----------
From: Carsten Mattner <carstenmattner at gmail.com>
Date: Sun, Aug 26, 2012 at 3:18 AM
Subject: Re: [xmonad] xmonad{,-contrib} on github
To: Michael Sloan <mgsloan at gmail.com>


On Sun, Aug 26, 2012 at 10:31 AM, Michael Sloan <mgsloan at gmail.com> wrote:
> I agree that the pull request system is non-ideal, but if you see
> people misusing it, just let them know.  Anything can be abused.
> Between topic branches and rebasing, it's fairly effective.

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.

> While it's unfortunate that whitespace problems aren't pointed out,
> whitespace differences are (and are represented much more intuitively
> than most diff formats), so it's pretty clear when you've introduced a
> whitespace problem.

Trailing whitespace changes are not visible AFAIR.
Mixed spaces and tabs is not visible.

> 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.

> https://github.com/haskell/cabal/pull/1003
> https://github.com/haskell-pkg-janitors/X11/pull/9
> https://github.com/haskell/HTTP/pull/27

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.

> 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'.

> 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.