[xmonad] RFC: XMonad.Prompt.ConfirmPrompt module

[Carsten Mattner]

On Thu, Mar 12, 2015 at 8:35 PM, Michael Sloan <mgsloan at gmail.com> wrote:
> 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

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

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

It doesn't solve the broken code review system.