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

[Michael Sloan]

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 <mgsloan at gmail.com>
Date: Sun, Aug 26, 2012 at 1:31 AM
Subject: Re: [xmonad] xmonad{,-contrib} on github
To: Carsten Mattner <carstenmattner at gmail.com>


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
<carstenmattner at gmail.com> wrote:
> 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.
>
> _______________________________________________
> xmonad mailing list
> xmonad at haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad