[xmonad] xmonad{,-contrib} on github

[Carsten Mattner]

On Sat, Aug 25, 2012 at 8:01 PM, Jochen Keil <jochen.keil at gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> lately I got a bit into github after being reluctant for a long time.
> My experiences were very positive after seeing how easy and fast it is
> to submit and merge patches (pull requests).
>
> Even if those patches are not accepted it is quite simple to follow
> the development and rebase your own patches. I have to admit that I'm
> a bit biased though. I mainly use git for most of my work, so the
> git/github workflow is very appealing to me.
>
> Another big point is, that I think switching to github could revive
> development for xmonad which is currently rather stale. Since git is
> very popular these days I'd figure that there are many potential
> contributors to xmonad on a github base.
>
> So I just ask around if anybody is also interested in this and would
> like to support my case. However, counter arguments are welcome too. :)

There's no point in doing that and I don't think xmonad development
has stalled at all. Although I have to use github as a contributor to
and maintainer of projects, I never like using the pull request
mechanism and am in the camp of people having asked for a way
to disable that feature like you can disable the wiki. Actually I
usually just download the patch(es) and git-am them locally.
Github is opaque and why should I let a closed source web app
muck around with my repository?

Centralizing everything in and around github negates what a dvcs
really set out to enable and solve. We need to use darcs/git as it's
intended and teach projects to have at least a second official
mirror kept in sync on a totally different server.

Both git and darcs work well and best via email because it's
another centralized (code review) mechanism you avoid.
With the right list server config - requiring reply-to-all - you will
reach the recipients even if the list itself on CC is temporarily
down and therefore being able to discuss a patch with the
list server (or github pull request server) not reachable.

Also github doesn't show you whitespace problems in patches
and you cannot edit the patches either as you can do locally.
Quite often the ease of use of github pull request results in
sloppy patches or not using topic branches and therefore
creating one pull request for each modification of a patch.

I could go on...

I'll stop here but will say that I see no problem with darcs.
It's a good tool and doesn't have to hide behind git or hg.
They're all adopting features from each other and getting
more similar. darcs need real world prominent users.

Instead of pull requests you can use things like patchwork
to gather and process patches from mails.