[xmonad] Fwd: xmonad{,-contrib} on github

Whoops meant to send this to the whole list. I'll attempt to add carsten's response as a reply to this. ---------- Forwarded message ---------- From: Michael Sloan Date: Sun, Aug 26, 2012 at 1:31 AM Subject: Re: [xmonad] xmonad{,-contrib} on github To: Carsten Mattner 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. 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. 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: https://github.com/haskell/cabal/pull/1003 https://github.com/haskell-pkg-janitors/X11/pull/9 https://github.com/haskell/HTTP/pull/27 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. 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 -Michael On Sat, Aug 25, 2012 at 1:58 PM, Carsten Mattner wrote:

On Sat, Aug 25, 2012 at 8:01 PM, Jochen Keil 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.

_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad