[xmonad] RFC: XMonad.Prompt.ConfirmPrompt module

[Antoine Beaupré]

hi

i have used this hack to have a confirmation prompt in xmonad before:

http://stackoverflow.com/questions/9993966/xmonad-confirmation-when-restarting

but i figured it would be cleaner to do this using only the xmonad<s
internal primitives, so i wrote this module.

could it be considered for inclusion in xmonad-contrib?

a.

[Carsten Mattner]

Post by Antoine Beaupré
hi
http://stackoverflow.com/questions/9993966/xmonad-confirmation-when-restarting
but i figured it would be cleaner to do this using only the xmonad<s
internal primitives, so i wrote this module.
could it be considered for inclusion in xmonad-contrib?

It's a desirable feature I'd use.

[Antoine Beaupré]

Post by Carsten Mattner

Post by Antoine Beaupré
hi
http://stackoverflow.com/questions/9993966/xmonad-confirmation-when-restarting
but i figured it would be cleaner to do this using only the xmonad<s
internal primitives, so i wrote this module.
could it be considered for inclusion in xmonad-contrib?

It's a desirable feature I'd use.

How do I go around doing that?

Thanks,

A.

[adam vogt]

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.

Thanks,
Adam

Post by Antoine Beaupré

Post by Carsten Mattner

Post by Antoine Beaupré
hi

http://stackoverflow.com/questions/9993966/xmonad-confirmation-when-restarting

Post by Carsten Mattner

Post by Antoine Beaupré
but i figured it would be cleaner to do this using only the xmonad<s
internal primitives, so i wrote this module.
could it be considered for inclusion in xmonad-contrib?

It's a desirable feature I'd use.

How do I go around doing that?
Thanks,
A.
--
In serious work commanding and discipline are of little avail.
- Peter Kropotkin
_______________________________________________
xmonad mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

[Antoine Beaupré]

Post by adam vogt
Antoine,
You've done enough (I've recorded a patch and put it into contrib).
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.

[Carsten Mattner]

Post by Antoine Beaupré

Post by adam vogt
Antoine,
You've done enough (I've recorded a patch and put it into contrib).
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?

[Carsten Mattner]

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

Post by Carsten Mattner

Post by Antoine Beaupré

Post by adam vogt
Antoine,
You've done enough (I've recorded a patch and put it into contrib).
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?

[Peter Jones]

Post by Carsten Mattner
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-code-open-source-project-hosting/

[Brandon Allbery]

Post by Peter Jones

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

http://arstechnica.com/information-technology/2015/03/google-to-close-google-code-open-source-project-hosting/

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

[Carsten Mattner]

Post by Brandon Allbery

Post by Peter Jones

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

http://arstechnica.com/information-technology/2015/03/google-to-close-google-code-open-source-project-hosting/

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.

[Carlos López-Camey]

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

Post by Carsten Mattner

Post by Brandon Allbery

Post by Peter Jones

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

http://arstechnica.com/information-technology/2015/03/google-to-close-google-code-open-source-project-hosting/

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
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

[Brandon Allbery]

Post by Carlos López-Camey
"Phabricator has more than 300,000 lines of PHP, so there are
probably at least sixty or seventy million security vulnerabilities in
the project."

GHC uses Phabricator. Some of them are none too keen on the PHP aspect (for
that matter, neither am I) but there seems little interest in moving away
from it.

Post by Carlos López-Camey
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..

My (possibly incorrect or outdated) understanding is that it's not too
difficult to convert a darcs repo to an equivalent git repo, but it's
essentially one-way as you can't associate the patches reliably between the
darcs and git repos.

[Carsten Mattner]

Post by Carlos López-Camey
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.

Post by Carlos López-Camey
"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.

Post by Carlos López-Camey
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.

Post by Carlos López-Camey

Post by Carsten Mattner

Post by Brandon Allbery

Post by Peter Jones

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

http://arstechnica.com/information-technology/2015/03/google-to-close-google-code-open-source-project-hosting/

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
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

[Alexander Sulfrian]

Post by Carlos López-Camey
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..

Currently I have a git mirror of xmonad[1] (because I am too lazy to get
the sources from darcs). It is using a darcs clone on the server and a
ruby script (darcs-to-git[2]) to synchronize the incoming changes to the
git repository.

Most of the times it works without problems only sometimes the darcs
clone does not refresh and I have to start from scratch (but thats maybe
because I do not know how to use darcs correctly).


Alex


1: http://git.animux.de/xmonad/
2: https://github.com/purcell/darcs-to-git

[Michael Sloan]

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

Post by Carsten Mattner

Post by Brandon Allbery

Post by Peter Jones

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

http://arstechnica.com/information-technology/2015/03/google-to-close-google-code-open-source-project-hosting/

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
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

[Carsten Mattner]

Post by Michael Sloan
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.

Compared to a system like Gerrit or Phab:

* you don't have a list of chronological state of the branch
with comments attached to them while not hiding old commits
once a branch fixup was applied. there's nothing wrong with
rebasing a branch and viewing a branch as a patchset is
the right and proven thing to do for anything nontrivial and small
* comments made in old commits are preserved but collapsed
and if it's collapsed you have to make an effort to find it in the
github web page once there's a new reply to the old (now hidden)
comment
* there's no clear hierarchy like say "these comments belong
to this patch state (aka branch state/rev)"
* comments made in commits aren't even picked up in the pull
request but only visible if you load the commit itself
* it's pretty much chaotic and they focus on syntax highlighting
and emojis as features sadly or so it appears

Post by Michael Sloan
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.

People use github and make do with its review system because
only few and between have used a tool like Gerrit or Phabricator
for reviewing code. You may find some insight in the recent
golang blogs about this very issue.

The reality is that projects tolerate and work around the problems
and use Github because of the social network effect and less
because the review system works.

Like everybody else who's used something more logical/capable
I can live with it, but it's up there with many things out of my
control that are unbearable which I have to tolerate because
I cannot fix it myself.

It's similar to going back from Haskell to C and losing all
the expressiveness features that aid in writing correct code.

Now Xmonad is not a project that can change this by making
a point and for instance Golang folks or Mozilla would have had
to be more vocal and critical of it to achieve mindshare and
change.

We may use Github but we must point out bugs and not
accept their model as the_truth if there's a proven better model
of working with patches.

If more people complain about it they may do something
about it, but as I said if you don't know how other tools
work better you don't see the bugs as easily.

I wish we had distributed issue tracking but there's just
Fossil's system that's production quality.

Post by Michael Sloan
https://github.com/github/hub It allows you to easily checkout a PR
simply by copy pasting its URL.

It doesn't solve the broken code review system.

[Peter Jones]

Post by Michael Sloan
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.

[adam vogt]

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

Post by Peter Jones

Post by Michael Sloan
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

[Carsten Mattner]

Post by adam vogt
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/

Post by adam vogt

Post by Peter Jones

Post by Michael Sloan
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

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

[Peter Jones]

Post by Carsten Mattner

Post by adam vogt
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/

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

[Carsten Mattner]

Post by Peter Jones

Post by Carsten Mattner

Post by adam vogt
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/

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

What do you mean?

[Peter Jones]

Post by Carsten Mattner

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

What do you mean?

Nothing more than what I said in my other selfish complaints. The
ability to know which patches have been submitted, if they are being
considered or have been rejected, etc.

[Carsten Mattner]

Post by Peter Jones

Post by Michael Sloan
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.

Post by Peter Jones
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.

[Michael Sloan]

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.

-Michael

Post by Peter Jones

Post by Michael Sloan
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

[Carsten Mattner]

Post by Michael Sloan
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.

Post by Michael Sloan

Post by Peter Jones

Post by Michael Sloan
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

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

[Francesco Ariis]

Post by Carsten Mattner
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.

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

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

[Carsten Mattner]

Post by Francesco Ariis

Post by Carsten Mattner
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.

Post by Francesco Ariis
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.

Post by Francesco Ariis
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.