On 2015-03-10 14:17:15, adam vogt wrote:

Antoine,

You've done enough (I've recorded a patch and put it into contrib).

Next time you could follow: https://wiki.haskell.org/Xmonad/xmonad_development_tutorial which goes over how to record a patch.

I admit I was scared to get into darcs again. :) Thanks! A. -- Having failed to discover weapons of mass destruction, Washington shifted its propaganda to "establishing democracy." That flatly refutes their earlier claim that the "only question" was whether Saddam would disarm. But with a sufficiently obedient intellectual class, and loyal media, the farce can proceed untroubled. - Noam Chomsky, in an interview about Irak

Ideally we could use Phabricator instance on haskell.org for Xmonad to have a proper code review (+extra) tool to avoid Github's super simplistic and insufficient review system that doesn't even preserve patch history. On Wed, Mar 11, 2015 at 1:05 PM, Carsten Mattner wrote:

On Tue, Mar 10, 2015 at 7:33 PM, Antoine Beaupre wrote:

...

On 2015-03-10 14:17:15, adam vogt wrote:

...

Antoine,

You've done enough (I've recorded a patch and put it into contrib).

Next time you could follow: https://wiki.haskell.org/Xmonad/xmonad_development_tutorial which goes over how to record a patch.

I admit I was scared to get into darcs again. :)

I don't have a problem with Darcs myself but I'm open to change my mind regarding Mercurial or Git migration even though I was against it the last time it was suggested here.

If a migration happens it should host the git repo on git.haskell.org, googlecode.com (where the issue tracker is) and wherever else, but a Github monoculture is dangerous and a crazybad idea. Fossil does it right with integrating tickets and docs in the repo but implementation details are not ideal. Github culture removes the D in DVCS for monetary and Facebook'ish lockin reasons and it's bad for everybody but Github.com shareholders.

Do we know how many contributors were put off by Darcs to not submit a patch and should do migrate or Mercurial or Git?

On Thu, Mar 12, 2015 at 1:21 PM, Peter Jones wrote:

Carsten Mattner writes:

...

If a migration happens it should host the git repo on git.haskell.org, googlecode.com (where the issue tracker is) and wherever else,

Looks like the issue tracker will need to move somewhere too:

http://arstechnica.com/information-technology/2015/03/google-to-close-google...

Yep, just saw that and was drafting a "we need to move everything soonish" message.... -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Hello Carsten, What do you think of hub.darcs.net? it supports darcs, project forks, and also issue reports. I liked the looks of phabricator, but check this "fact": "Phabricator has more than 300,000 lines of PHP, so there are probably at least sixty or seventy million security vulnerabilities in the project." Personally i am neutral on moving to git, I think darcs is robust. However, there is no reason why there shouldn't be any git mirrors :) In fact, i tried doing that in the past. but I don't know if there's a solution to maintain git and darcs synced.. 2015-03-12 12:24 GMT-06:00 Carsten Mattner :

On Thu, Mar 12, 2015 at 6:37 PM, Brandon Allbery wrote:

...

On Thu, Mar 12, 2015 at 1:21 PM, Peter Jones wrote:

...

Carsten Mattner writes:

...

If a migration happens it should host the git repo on git.haskell.org, googlecode.com (where the issue tracker is) and wherever else,

Looks like the issue tracker will need to move somewhere too:

http://arstechnica.com/information-technology/2015/03/google-to-close-google...

Yep, just saw that and was drafting a "we need to move everything soonish" message....

I say move to git.haskell.org and phabricator.haskell.org as the primary place as github refuses to fix their code review system. Github's systems works enough to seem nice but falls down if you actually review code:

1. no patch history 2. horrendous comment system in reviews 3. new comments as replies to previous ones are hidden and hard to find if you don't manually look for them in the code comments

I don't want to be direct, but github's code review and comment system is superbad. _______________________________________________ xmonad mailing list xmonad@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

On Thu, Mar 12, 2015 at 8:05 PM, Carlos López-Camey wrote:

Hello Carsten, What do you think of hub.darcs.net? it supports darcs, project forks, and also issue reports.

If Darcs is kept sure why not.

I liked the looks of phabricator, but check this "fact":

"Phabricator has more than 300,000 lines of PHP, so there are probably at least sixty or seventy million security vulnerabilities in the project."

Yeah, Phabricator has bugs, but it was chosen instead of Gerritt, and there are people maintaining it and Facebook will fix bugs, so the proper code review and workflow it provides is worth the bugginess if you ask me. Arcanis (the command line tool) is also opinionated and messes up clean history of topic branches by collapsing it into one single commit so that's a problem. We have to ask the GHC contributors how they deal with that as single commit per branch is so CVS/SVN-ish and makes bisecting bugs impossible.

Personally i am neutral on moving to git, I think darcs is robust. However, there is no reason why there shouldn't be any git mirrors :) In fact, i tried doing that in the past. but I don't know if there's a solution to maintain git and darcs synced..

Me too, but it seems people feel more comfortable with git, and if it increases the chances of small contributions by users who'd otherwise skip due to Darcs, I'd say it's worth the migration. I'm not neutral on Github though. It's a failure of the FOSS community that everybody treats it like it's the new TCP of code hosting. And as I said their focus is on unimportant stuff while making their code reviews worse. Recently they changed diffs to be syntax highlighted which is a bad idea because it makes RED (delete) GREEN (ADD) unified diff visualizations harder to read (scan). Not to mention code comments being unusable but I'm repeating myself.

2015-03-12 12:24 GMT-06:00 Carsten Mattner :

...

On Thu, Mar 12, 2015 at 6:37 PM, Brandon Allbery wrote:

...

On Thu, Mar 12, 2015 at 1:21 PM, Peter Jones wrote:

...

Carsten Mattner writes:

...

If a migration happens it should host the git repo on git.haskell.org, googlecode.com (where the issue tracker is) and wherever else,

Looks like the issue tracker will need to move somewhere too:

http://arstechnica.com/information-technology/2015/03/google-to-close-google...

Yep, just saw that and was drafting a "we need to move everything soonish" message....

I say move to git.haskell.org and phabricator.haskell.org as the primary place as github refuses to fix their code review system. Github's systems works enough to seem nice but falls down if you actually review code:

1. no patch history 2. horrendous comment system in reviews 3. new comments as replies to previous ones are hidden and hard to find if you don't manually look for them in the code comments

I don't want to be direct, but github's code review and comment system is superbad. _______________________________________________ xmonad mailing list xmonad@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

I am greatly in favor of moving to git. Apologies for the laziness, but I've been sitting on some cleanup patches to one of my XMonadContrib modules for a year or two now, because I haven't taken the time to figure out how to push to darcs / get it reviewed / etc. My XMonad configuration has grown quite large with sections labeled "potential XMonadContrib module?". These weaknesses of github are pretty much only present when you are rebasing / force pushing the review branch. What do you mean by "no patch history"? The old commits are still visible, along with their comments. What is wrong with the comment system? I get notifications for comment replies, so I haven't experienced them being hidden. In my experience, the PR system works fine. Certainly worse exist, personally I've had quite bad experiences with gerrit. I realize that Torvalds himself takes issue with it, but it seems to work just fine for all the haskell projects on github (it seems like the majority of them). Is a philosophical issue like this really a good reason to ignore the positive network effects of hosting on github? People are familiar with github, and so this lowers the barrier to entry. . The hub tool helps quite a lot with reviewing PRs: https://github.com/github/hub It allows you to easily checkout a PR simply by copy pasting its URL. I think we could see a revitalization of XMonad if such barriers to contribution are lowered. I would certainly be more likely to contribute patches. -Michael On Thu, Mar 12, 2015 at 11:24 AM, Carsten Mattner wrote:

On Thu, Mar 12, 2015 at 6:37 PM, Brandon Allbery wrote:

...

On Thu, Mar 12, 2015 at 1:21 PM, Peter Jones wrote:

...

Carsten Mattner writes:

...

If a migration happens it should host the git repo on git.haskell.org, googlecode.com (where the issue tracker is) and wherever else,

Looks like the issue tracker will need to move somewhere too:

http://arstechnica.com/information-technology/2015/03/google-to-close-google...

Yep, just saw that and was drafting a "we need to move everything soonish" message....

I say move to git.haskell.org and phabricator.haskell.org as the primary place as github refuses to fix their code review system. Github's systems works enough to seem nice but falls down if you actually review code:

1. no patch history 2. horrendous comment system in reviews 3. new comments as replies to previous ones are hidden and hard to find if you don't manually look for them in the code comments

I don't want to be direct, but github's code review and comment system is superbad. _______________________________________________ xmonad mailing list xmonad@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

Michael Sloan writes:

I think we could see a revitalization of XMonad if such barriers to contribution are lowered. I would certainly be more likely to contribute patches.

I just submitted my first patch and I can say that Darcs didn't cause me any issues. There's been a lot of talk about code review system but what are we using right now for XMonad? I can say that I certainly don't like the idea of submitting patches to a mailing list. I have no idea if the patches I've submitted have been seen or will fall off the fold as new messages come in. -- Peter Jones, Founder, Devalot.com Defending the honor of good code

On Thu, Mar 12, 2015 at 10:00 PM, adam vogt wrote:

We previously had darcswatch to list patches that were emailed. But Joachim took it down and I think it missed some patches anyhow.

Linux kernel, Samba and other projects are using Patchwork that works by monitoring the list. http://patchwork.coreboot.org/patch/2703/ http://patchwork.ozlabs.org/project/netdev/list/ http://patchwork.linux-mips.org/project/linux-mips/list/

On Mar 12, 2015 4:33 PM, "Peter Jones" wrote:

...

Michael Sloan writes:

...

I think we could see a revitalization of XMonad if such barriers to contribution are lowered. I would certainly be more likely to contribute patches.

I just submitted my first patch and I can say that Darcs didn't cause me any issues.

There's been a lot of talk about code review system but what are we using right now for XMonad? I can say that I certainly don't like the idea of submitting patches to a mailing list. I have no idea if the patches I've submitted have been seen or will fall off the fold as new messages come in.

-- Peter Jones, Founder, Devalot.com Defending the honor of good code

_______________________________________________ xmonad mailing list xmonad@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

_______________________________________________ xmonad mailing list xmonad@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

On Thu, Mar 12, 2015 at 10:19 PM, Peter Jones wrote:

Carsten Mattner writes:

...

On Thu, Mar 12, 2015 at 10:00 PM, adam vogt wrote:

...

We previously had darcswatch to list patches that were emailed. But Joachim took it down and I think it missed some patches anyhow.

Linux kernel, Samba and other projects are using Patchwork that works by monitoring the list.

http://patchwork.coreboot.org/patch/2703/http://patchwork.ozlabs.org/project... http://patchwork.linux-mips.org/project/linux-mips/list/

It would be nice to have a little more visibility into the patch submission/review process.

What do you mean?

On Thu, Mar 12, 2015 at 9:33 PM, Peter Jones wrote:

Michael Sloan writes:

...

I think we could see a revitalization of XMonad if such barriers to contribution are lowered. I would certainly be more likely to contribute patches.

I just submitted my first patch and I can say that Darcs didn't cause me any issues.

There's been a lot of talk about code review system but what are we using right now for XMonad? I can say that I certainly don't like the

Manual system of a mailing list which is crude but at least doesn't fail while trying to be smart about it and there's a clear patch review history in the list archives.

idea of submitting patches to a mailing list. I have no idea if the patches I've submitted have been seen or will fall off the fold as new messages come in.

This can happen with any system where maintainers have read but not commented yet for some reason.

On Thu, Mar 12, 2015 at 10:09 PM, Michael Sloan wrote:

Certainly! It didn't cause me issues 7 or 8 years ago when I wrote those modules in the first place. Point is, I haven't used darcs in that time, and so how to use it has faded. I could create a git branch and submit a pull request in under a minute.

Let me re-iterate that this is due to supreme laziness, primarily due to these cleanups being unimportant. It's more of a vanity thing, as I wrote the code back when I was still new to Haskell.

I'm all in favor of facilitating more contributions and don't mind a git migration for that.

On Thu, Mar 12, 2015 at 1:33 PM, Peter Jones wrote:

...

Michael Sloan writes:

...

I think we could see a revitalization of XMonad if such barriers to contribution are lowered. I would certainly be more likely to contribute patches.

I just submitted my first patch and I can say that Darcs didn't cause me any issues.

There's been a lot of talk about code review system but what are we using right now for XMonad? I can say that I certainly don't like the idea of submitting patches to a mailing list. I have no idea if the patches I've submitted have been seen or will fall off the fold as new messages come in.

-- Peter Jones, Founder, Devalot.com Defending the honor of good code

_______________________________________________ xmonad mailing list xmonad@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

---

xmonad mailing list xmonad@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

On Fri, Mar 13, 2015 at 12:36 AM, Francesco Ariis wrote:

On Wed, Mar 11, 2015 at 01:05:06PM +0100, Carsten Mattner wrote:

...

Do we know how many contributors were put off by Darcs to not submit a patch and should do migrate or Mercurial or Git?

I submitted a very small patch to Xmonad some time ago. The guide provided to submit a patch was clear, darcs UI very intuitive, the submit-to-mailing-list path streamlined.

An herein lies the gist of if what separates those who favor quick patching via Github's web interface from those who not only submit a patch but are also very likely to stay around answering questions or maintaining a module. Not saying git is a worse tool it's just not the limiting factor in contributing for serious contributors and trivial patches can be done based on someone's suggestion or diff without further contributor involvement. But if git injects new blood into Xmonad development let's migrate. Hey we can start off by fixing the screenshot links on the homepage and doing stable releases.

I cannot digest git; it is much more unfriendly to the "casual contributor" to me, I often end up frustrated using it. It is a very popular choice though (even if I would expect someone contributing to a Haskell project to at least have heard of Darcs).

Git is like the C of vcs. it is very flexible and you can mold it to your workflow perfectly but it's very easy to mess up. Darcs is like other tools with a streamlined workflow that might limit its flexibility but serves a well defined purpose. So far git's data structures first design has proven to be a good decision.

And yes, I must admit it, it feels nice using (and hence generating important feedback) a tool developed in Haskell, by Haskellers, for Haskeller.

Add Yi and it's the perfect trio.