From: Carsten Mattner 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

Jochen, I understand (someone does the Githubber's Witnesses thing every couple months or so in the various projects I work with) that git users are generally offended that anyone still uses something other than git, but truly not everyone wants to or needs to switch. At some point you may actually have to accept that other version control systems exist instead of evangelizing that everyone must switch to your One True System. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On Mon, Aug 27, 2012 at 9:19 PM, Brandon Allbery wrote:

Jochen, I understand (someone does the Githubber's Witnesses thing every couple months or so in the various projects I work with) that git users are generally offended that anyone still uses something other than git, but truly not everyone wants to or needs to switch. At some point you may actually have to accept that other version control systems exist instead of evangelizing that everyone must switch to your One True System.

Seconded. While it's good to bring up alternatives, I don't like evangelizing things at all. Use what works for you. It's good to have a choice. Monoculture is a problem and making github even more central and prominent than it already is is not a good thing for us all. If anything we need to get darcsden and friends enhanced. Having all three dvcs'es used will put more pressure on content transportability between them and help in the long run. I think all three are nurturing each other.

On Mon, Aug 27, 2012 at 8:55 PM, Jochen Keil wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hello,

On 27.08.2012 00:43, Michael Sloan wrote:

...

...

From: Carsten Mattner 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. You don't need to accept such commits. Just reject them and ask people to provide proper author information.

Of course I don't but I have to look at the pull/ID.patch to get at the info and that's kind of hidden and advanced which may be the reason why there are projects with useless commit author entries.

...

...

To be safe I have to doubt the quality of a patch if the contributor cannot be bothered to learn use the vcs properly. I'm sorry, but that sounds a bit ignorant to me..

I feared that might be misinterpreted, it wasn't meant to sound like that but time is valuable and if someone cannot be bothered to configure and learn to use tools. I'm of the mindset to understand and learn tools I use but maybe you're talking about casual users of xmonad who are not developers and still want to contribute. It's not an important point anyways, let's move on :-).

...

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. I second that. The entry barrier for less tech-savvy users is much lower. Giving these people an easy to use interface like github would likely lead to an increase of contributions to xmonad's development.

We'll have to agree that I fail to see how github's website makes anything easy or better. It may only be me and my brain may be wired differently. I won't argue about why it's easier for you or others, I just cannot understand or see how that's true. Let's agree we won't be able to see each other's point of view and move on :-). That's normal as we're thankfully not all of the same personality.

...

...

...

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

It is not easier to send an email, when you have to set up the whole system yourself. Most people use web based mailing services like gmail and configuring the mta of your standard linux distribution to make use of that can be quite a burden for the non-initiated.

You don't usually do that but just use msmtp or git's imap client and do nothing more than configure your mua. Both approaches and even git itself support credential stores and caching. I see your argument and can imagine some people feel like that's easier.

...

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. I couldn't agree more with that. Whenever there would be a problem with github or in case you just don't like it anymore, return to the standard email/remote-pull git workflow.

- From my point of view there is nothing lost by using github, but much value added. Github is like a nice web interface for git. The underlying system will work fine without it.

Another point I'd like to make is the switch to git in general. I guess there are many potential users out there who would be willing to contribute if they could work with git. Personally I can't see an advantage of darcs over git, but I don't want to start a vcs flame here. I probably just don't know enough about darcs.

I do use a lot of git and like and am most comfortable with it due to extensive use but after using darcs for xmonad I don't find it hard or complicated. We should support darcs and ghc by using it and supporting it as a real world user. I'm sure python projects love to use mercurial for obvious reasons.

Quoting wagnerdm@seas.upenn.edu:

Submitted patches are already centrally tracked at http://darcswatch.nomeata.de/repo_http:__code.haskell.org_xmonad.html The xmonad-contrib repository isn't, but I don't think anybody would object to adding it.

Uh, and by "the xmonad-contrib repository isn't", I really mean "the xmonad-contrib repository is, but I misspelled it when searching". http://darcswatch.nomeata.de/repo_http:__code.haskell.org_XMonadContrib.html ~d

On Mon, Aug 27, 2012 at 5:49 AM, wrote:

...

Submitted patches are already centrally tracked at http://darcswatch.nomeata.de/repo_http:__code.haskell.org_xmonad.html

They're *supposed* to be tracked there, but as I've complained to nomeata in the past, the service seems broken - I'm pretty sure there's more than just 1 patch bundle for XMC outstanding. This is why I haven't done a patch roundup in months and months. -- gwern http://www.gwern.net