By allowing people to easily publish a completed work, and making it
easier for them to let others peek at their work, Git hosting
services like GitHub are wonderful. But I am not conviced that
quality code reviews like we do on the mailing list can be done with
existing Web based interface to a satisfactory degree.
Patches with proposed commit log messages are sent via e-mail,
people can review them and comment on them with quotes from the
relevant part of the patch. The review can even be made offline,
yet at the end, the list archive is an easy one-stop location you
need to go to see how the changes progressed, what the background
thinking was, etc. for all the changes that matter.
Look at recent ones (randomly, $gmane/199492, $gmane/199497,
$gmane/200750, $gmane/201477, $gmane/201434), and their re-rolls,
and admire how well the process works.
I've played with GitHub's in-line code comment interface, but
honestly, it is cumbersome to use, for one thing, but more
importantly, you have to click around various repositories of pull
requestors, dig around to see in-line comments, and I do not see how
we can keep a coherent "discussion" like we do on the mailing list.
There may be a hosting site with better code review features, but
all the code review of Git happens on this mailing list, and that is
not likely to change in the near future.
[Footnote]
$gmane stands for http://thread.gmane.org/gmane.comp.version-control.git/
in the above description.
On Wed, Jul 18, 2012 at 2:49 AM, Junio C Hamano [off-list ref] wrote:
There may be a hosting site with better code review features, but
all the code review of Git happens on this mailing list, and that is
not likely to change in the near future.
For me, you know, it's codereview, aka rietveld. [1]
[1] code.google.com/p/rietveld/
From: Michael G Schwern <hidden> Date: 2016-06-15 22:54:19
On 2012.7.17 10:49 PM, Junio C Hamano wrote:
By allowing people to easily publish a completed work, and making it
easier for them to let others peek at their work, Git hosting
services like GitHub are wonderful. But I am not conviced that
quality code reviews like we do on the mailing list can be done with
existing Web based interface to a satisfactory degree.
In this instance, I was just using Github for repository storage. I was
hoping I could just submit a remote git repository and people would look at it
from there. No Github required.
I understand this makes things very convenient for you to review patches, let
me convey my POV...
After I'm exhausted from volunteering all the coding work, rather than
submitting a URL to a remote repository I find I have to learn new specialized
tools. It's extra learning and work, an extra step to screw up, and foreign
to me (even as a experienced git user). It is of little benefit to me as a
casual volunteer submitter.
I can see if you've been on the git mailing list for a while and have git-am
and all that set up, this system is great. But it comes at a cost which is
offloaded onto new and casual contributors.
Patches with proposed commit log messages are sent via e-mail,
people can review them and comment on them with quotes from the
relevant part of the patch. The review can even be made offline,
yet at the end, the list archive is an easy one-stop location you
need to go to see how the changes progressed, what the background
thinking was, etc. for all the changes that matter.
Look at recent ones (randomly, $gmane/199492, $gmane/199497,
$gmane/200750, $gmane/201477, $gmane/201434), and their re-rolls,
and admire how well the process works.
I've played with GitHub's in-line code comment interface, but
honestly, it is cumbersome to use, for one thing, but more
importantly, you have to click around various repositories of pull
requestors, dig around to see in-line comments, and I do not see how
we can keep a coherent "discussion" like we do on the mailing list.
There may be a hosting site with better code review features, but
all the code review of Git happens on this mailing list, and that is
not likely to change in the near future.
Everything you've said above is correct... but it creates a procedure
optimized for the convenience of the long time reviewers at the expense of new
and casual submissions. I'm going to guess you live in email and have your
client setup to do fancy things to extract patches from your mailbox and the like.
This sort of specialized setup makes people bounce right off the submission
process. At OSCON I was asking around for help getting things setup so I
could submit patches here properly. As soon as they said "which mail daemon
are you running?", I said "stop! I don't want to know any more". I have too
many things to do to be fiddling with my mailer configuration just to submit
volunteer work in the right form (that said, I'm pleased as punch that
git-send-email now has instructions for sending via GMail). You're
volunteers, too. We're all volunteers, so a more balanced submission process
would be nice.
But since you brought Github up... (I get the impression its kind of a dirty
word around here)
As somebody who doesn't live in email anymore (once upon a time I did), I find
the Github Pull Request model to be an excellent... I'm not even going to use
the word "compromise" because I don't feel like either side has been
compromised... it's an excellent enhancement. The commits and conversations
about the commits are all there on one page. Looking at a commit is a click
away (I usually open them all in tabs at once, much faster). You can comment
on them as a whole or inline. Those comments appear BOTH in the commit AND in
the larger conversation on the pull request keeping it coherent, no clicking
around. And it has email mirroring. All that and its tracked and organized
in an issue tracker.
Here's an example that includes commits, discussion about the larger issue,
comments on commits, more commits based on those comments, and so on. As you
can see, the conversation is complete and coherent. It wasn't always this
way, but they're constantly improving.
https://github.com/schwern/test-more/pull/319
A concrete downside it is that it does not work offline. I agree that's a
problem. I don't think it's a veto. There are various work arounds which are
less complicated than your typical git-to-email-to-git setup. We can talk
about that you're interested.
I've gone all in on Github Pull Requests such that most of my projects don't
even have mailing lists (issues are used for discussion). This avoids a split
community between Github and the mailing list. And they have email mirroring,
so issue discussion can be done all in email (I prefer email for things that
involve push notification and replies).
Github has a nice API and it would be possible to create a Github Pull Request
<-> Mailing List gateway. Perl 5 uses something like that for bug reports.
All bug reports submitted via web or email all go into a bug tracker. All
discussion on the web is mirrored to a thread on the mailing list and vice
versa. Web users are happy. Mailing list users are happy. Everything is
archived and organized in the tracker.
If you were interested in going down this road, I'd be interested in helping.
Step one would be to have pull requests on Github posted to the mailing list.
Link to the pull request, links to each individual commit. Then those who
want to work on Github can do it. Step two would be to have activity on the
pull request mirrored back to the list, still a SMOP. Step three would be to
have replies on the list mirrored back into the Github discussion. It could
even submit the pull request with git-send-email and mirror individual replies
to patches back as comments on individual Github commits.
If all the clicking and opening tabs in a browser feels uncomfortable to
you... its something you learn like anything else. Less and less people are
comfortable in mail clients. Who is the system optimized for? It doesn't
have to be a zero sum game.
If you're interested, I'd be happy to help put something like this together if
it will break the "ease of review" vs "ease of submission" deadlock.
--
Don't try the paranormal until you know what's normal.
-- "Lords and Ladies" by Terry Prachett
From: Eric Wong <hidden> Date: 2016-06-15 22:54:19
Michael G Schwern [off-list ref] wrote:
On 2012.7.17 10:49 PM, Junio C Hamano wrote:
quoted
By allowing people to easily publish a completed work, and making it
easier for them to let others peek at their work, Git hosting
services like GitHub are wonderful. But I am not conviced that
quality code reviews like we do on the mailing list can be done with
existing Web based interface to a satisfactory degree.
In this instance, I was just using Github for repository storage. I was
hoping I could just submit a remote git repository and people would look at it
from there. No Github required.
I understand this makes things very convenient for you to review patches, let
me convey my POV...
After I'm exhausted from volunteering all the coding work, rather than
submitting a URL to a remote repository I find I have to learn new specialized
tools. It's extra learning and work, an extra step to screw up, and foreign
to me (even as a experienced git user). It is of little benefit to me as a
casual volunteer submitter.
Except git is also a "new specialized tool". Your examples are exactly
why I'm saddened many projects only adopted git, but not the workflow
which _built_ git (and Linux).
I can see if you've been on the git mailing list for a while and have git-am
and all that set up, this system is great. But it comes at a cost which is
offloaded onto new and casual contributors.
Email is integral to Free/Open Source development and remains one of the
few things on the Internet not (yet) controlled by any central entity.
Once setup, the same email setup can work across all projects which use
email. These projects need not be hosted on the same websites/servers
at all.
This sort of specialized setup makes people bounce right off the submission
process. At OSCON I was asking around for help getting things setup so I
could submit patches here properly. As soon as they said "which mail daemon
are you running?", I said "stop! I don't want to know any more". I have too
many things to do to be fiddling with my mailer configuration just to submit
volunteer work in the right form (that said, I'm pleased as punch that
git-send-email now has instructions for sending via GMail). You're
volunteers, too. We're all volunteers, so a more balanced submission process
would be nice.
How about we educate users about a proper email setup instead? If
they're capable of learning git, they're surely capable of setting up an
email client properly, and perhaps more projects can adopt an
email-centric workflow.
But since you brought Github up... (I get the impression its kind of a dirty
word around here)
(Not speaking for the git project) I'm entirely against the way GitHub
(or Ohloh or similar services) gamifies software development and tries
to tie a person to all their other projects.
Much of my code is public, but I am a private person. I want code to be
judged solely on its own merits of that code; not from what the author's
achieved or how "popular" the person might be in the development world.
Unfortunately, GitHub (and other social networks) is structured to
encourage that sort of thing (which I know is appealing to many).
For me, the whole social network followers/timeline thing also has a
_huge_ creepiness factor to it. How one prioritizes and spends time
between different different (especially unrelated) projects should be
nobody else's business.
I don't make it /easy/ for someone (e.g. Junio) to know I'm slacking
off on my git work to hack on ProjectNoOneUses :)
One could try using a different account for every project, but that's
also violating the terms of service.
If all the clicking and opening tabs in a browser feels uncomfortable to
you... its something you learn like anything else. Less and less people are
comfortable in mail clients. Who is the system optimized for? It doesn't
have to be a zero sum game.
(Still not speaking for others) I believe GUIs are (mostly) harmful.
Graphical browsers don't interact well with command-line tools.
Browsers have no concept of a working directory; I can't fire up a
browser tab/window for each project I work on and edit/apply patches
directly from the browser like I can with an MUA.
We need to figure out how to teach folks to use email (properly)
instead.
From: Michael G Schwern <hidden> Date: 2016-06-15 22:54:20
On 2012.7.24 7:55 PM, Eric Wong wrote:
quoted
After I'm exhausted from volunteering all the coding work, rather than
submitting a URL to a remote repository I find I have to learn new specialized
tools. It's extra learning and work, an extra step to screw up, and foreign
to me (even as a experienced git user). It is of little benefit to me as a
casual volunteer submitter.
Except git is also a "new specialized tool". Your examples are exactly
why I'm saddened many projects only adopted git, but not the workflow
which _built_ git (and Linux).
There is an important difference between a tool which is useful for one or two
projects and one which is useful for a broad spectrum of projects. I learn
git once (or diff or bash or Perl or whatever) and I'm going to use it again
and again all over the place. I learn git-send-email and (if I'm not a kernel
developer) I'm going to use it on a handful of projects maybe. It's O(1) vs
O(n) effort.
Github also has broad spectrum utility. I learn how to fork and work with a
Github pull request once, and I can repeat that on thousands of different
projects of all different sorts of things.
This commonality of tools and techniques is very important to easing the on
ramp for new (to-your-project) developers.
quoted
I can see if you've been on the git mailing list for a while and have git-am
and all that set up, this system is great. But it comes at a cost which is
offloaded onto new and casual contributors.
Email is integral to Free/Open Source development and remains one of the
few things on the Internet not (yet) controlled by any central entity.
Once setup, the same email setup can work across all projects which use
email. These projects need not be hosted on the same websites/servers
at all.
While I hear your concern about being centrally controlled, it is largely
irrelevant to the new user experience. And remaining independent does not
mean you can't use web tools. Be wary of a false dichotomy between Free and web.
"We use a mailing list" is by no means an indication of commonality. Every
project of the "send patches to the list" form has their own quirks and ways
of doing it. Usually they're not written down. This is what I've been
struggling with. I've been sending patches to mailing lists for decades and I
can tell you everybody does it differently. "Send a patch to the list" is one
of the steeper project on-ramps.
quoted
This sort of specialized setup makes people bounce right off the submission
process. At OSCON I was asking around for help getting things setup so I
could submit patches here properly. As soon as they said "which mail daemon
are you running?", I said "stop! I don't want to know any more". I have too
many things to do to be fiddling with my mailer configuration just to submit
volunteer work in the right form (that said, I'm pleased as punch that
git-send-email now has instructions for sending via GMail). You're
volunteers, too. We're all volunteers, so a more balanced submission process
would be nice.
How about we educate users about a proper email setup instead? If
they're capable of learning git, they're surely capable of setting up an
email client properly, and perhaps more projects can adopt an
email-centric workflow.
SubmittingPatches would be helped by that, particularly with a clear
step-by-step example of using git-send-email and all its numerous command line
switches.
I was showing Jonathan the guide I have for releasing Perl modules which is
both A) step-by-step and also B) covers the numerous little problems that are
usually only in somebody's head or scattered around the docs. It was built in
order to allow a person who had never released a module to release a module.
Then we watched just such a person follow the directions. As they asked
questions, struggled or made mistakes we filled in the gaps in the docs.
https://github.com/scrottie/autobox-Core/wiki/How-To-Make-A-Release
But this is also not about capability. Yes, people are capable of figuring
out git-send-email, but its Yet Another Special Thing to learn before they can
submit a patch and call their work done. Volunteers, especially brand new
ones, have only so much volunteerism to burn before they'll walk away. You
want them burning that on productive patching and contributions, not learning
specialty tools.
And, finally, the last thing most people want is more email. Seriously. It
sounds like you live in your mailer, but fewer and fewer people do that. Me?
I don't want to join another mailing list. My email management is a disaster!
What it comes down to is this: is it enough to contribute to git.git to know
how to work on git.git? Or do you also need to live in your mailer? Bolt on
that extra requirement and you lose a large swath of contributors.
quoted
But since you brought Github up... (I get the impression its kind of a dirty
word around here)
(Not speaking for the git project) I'm entirely against the way GitHub
(or Ohloh or similar services) gamifies software development and tries
to tie a person to all their other projects.
Much of my code is public, but I am a private person. I want code to be
judged solely on its own merits of that code; not from what the author's
achieved or how "popular" the person might be in the development world.
Unfortunately, GitHub (and other social networks) is structured to
encourage that sort of thing (which I know is appealing to many).
FWIW this aspect of Github is just a toy. For some people it acts as a
carrot, but nobody worth caring about takes it seriously. I wouldn't get too
worked up about it.
For me, the whole social network followers/timeline thing also has a
_huge_ creepiness factor to it. How one prioritizes and spends time
between different different (especially unrelated) projects should be
nobody else's business.
I don't make it /easy/ for someone (e.g. Junio) to know I'm slacking
off on my git work to hack on ProjectNoOneUses :)
One could try using a different account for every project, but that's
also violating the terms of service.
You want to know what's creepy? That you'd think people work like that.
It doesn't work out that way. People have far better things to do than stalk
your Github commits to see how you're spending your time. You're just not
that interesting. Neither am I!
(If I really wanted to I could just compile your activity from public list
archives and repositories, so you're really not broadcasting any less
information about yourself by staying off Github. But I wouldn't want to,
because you're just not that interesting and I have better things to do with
my time!)
Besides, Facebook is where all the stalking is at! ;)
quoted
If all the clicking and opening tabs in a browser feels uncomfortable to
you... its something you learn like anything else. Less and less people are
comfortable in mail clients. Who is the system optimized for? It doesn't
have to be a zero sum game.
(Still not speaking for others) I believe GUIs are (mostly) harmful.
You can hate GUIs, but you should also realize that just about everyone out
there likes them, and they're not all morons. If you deny GUIs as a tool for
git.git developers because of your blind spot, then you're losing potential
contributors. More and more as time goes on.
Recognize it as a personal blind spot, don't punish your users because of it.
Me? I hate IDEs. Won't touch em. Do I really think emacs or vim are
superior and all those IDE users are deluded? HELL NO! I think I'm ignorant
and don't understand IDEs. I really don't know anything about them. I don't
even know what I don't know. I generally keep my mouth shut and listen rather
than blab a bunch of old guy ignorance.
Graphical browsers don't interact well with command-line tools.
Browsers have no concept of a working directory; I can't fire up a
browser tab/window for each project I work on and edit/apply patches
directly from the browser like I can with an MUA.
I'm not sure what you're talking about, or what sort of workflow you've got
going with your mailer, but I'm sure with just as much time and effort as
you've put into your CLI and MUA setup you can be just as efficient or moreso
GUI. One can do crazy shit in browsers these days either in Javascript or by
writing or using an add-on. But also, one doesn't have to do EVERYTHING with
a single tool. Amazing But True!
You should consider sitting down with somebody who works very differently from
how you do and see how they do it. You might learn something you don't know
you don't know!
And again, it *does not have to be zero sum*. It doesn't have to be email VS
GUI. You can have your cake and eat it too.
--
125. Two drink limit does not mean two kinds of drinks.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:54:20
Michael G Schwern wrote:
And again, it *does not have to be zero sum*. It doesn't have to be email VS
GUI. You can have your cake and eat it too.
I assume you're talking about web-based interfaces that have gateways
to email, that produce inboxes like this:
24 Jul 02:46 GitHub [github] msysgit/msysgit was forked by peters
23 Jul 10:27 GitHub [msysgit/git] ce8ebc: vcs-svn: rename check_o
23 Jul 10:01 GitHub [github] Comment created on issue 44 (new git
23 Jul 09:50 GitHub [github] Comment created on issue 44 (new git
23 Jul 09:33 GitHub [github] Comment created on issue 44 (new git
23 Jul 09:39 GitHub [github] Comment created on issue 24 (Long fi
23 Jul 09:31 GitHub [github] Comment created on issue 44 (new git
23 Jul 09:30 GitHub [github] Comment created on issue 24 (Long fi
22 Jul 23:57 GitHub [github] Comment created on issue 44 (new git
I call that pretending to have my cake, rather than having it. :)
Maybe some day someone will prove me wrong and make a nice web-based
tool that I don't even need to know about that mines project mailing
lists. If I have to tweak my subject lines a little to help it out,
that's fine with me. I think patchwork is supposed to work this way.
But unless we're talking about splitting the mailing list into a bunch
of mini mailing lists (like some bug trackers do), it doesn't change
anything fundamental, so I'm not sure why we're discussing this.
Ciao,
Jonathan
From: Michael G Schwern <hidden> Date: 2016-06-15 22:54:20
On 2012.7.24 10:54 PM, Jonathan Nieder wrote:
quoted
And again, it *does not have to be zero sum*. It doesn't have to be email VS
GUI. You can have your cake and eat it too.
I assume you're talking about web-based interfaces that have gateways
to email, that produce inboxes like this:
24 Jul 02:46 GitHub [github] msysgit/msysgit was forked by peters
23 Jul 10:27 GitHub [msysgit/git] ce8ebc: vcs-svn: rename check_o
23 Jul 10:01 GitHub [github] Comment created on issue 44 (new git
23 Jul 09:50 GitHub [github] Comment created on issue 44 (new git
23 Jul 09:33 GitHub [github] Comment created on issue 44 (new git
23 Jul 09:39 GitHub [github] Comment created on issue 24 (Long fi
23 Jul 09:31 GitHub [github] Comment created on issue 44 (new git
23 Jul 09:30 GitHub [github] Comment created on issue 24 (Long fi
22 Jul 23:57 GitHub [github] Comment created on issue 44 (new git
I call that pretending to have my cake, rather than having it. :)
That's kind of like pointing at RCS and saying "version control sucks and its
pointless to try and make it better!" Mail gateways built by web sites suck
because they live in the web browser and email is an after thought. Sound
familiar?
Here is a much better example of the RT mail gateway that Perl 5 development
uses. They're a dev community still centered around email, so it has to
integrate well.
http://www.nntp.perl.org/group/perl.perl5.porters/2012/07/msg189716.html
And the corresponding ticket in the tracker.
https://rt.perl.org/rt3/Public/Bug/Display.html?id=113684
The initial report comes in either via the web tracker or via a command line
program (perlbug) that sends an email to the list. Replies on either the
tracker or the mailing list are mirrored. Duplicates are detected etc...
That's the sort of mail gateways I'm used to.
Maybe some day someone will prove me wrong and make a nice web-based
tool that I don't even need to know about that mines project mailing
lists. If I have to tweak my subject lines a little to help it out,
that's fine with me. I think patchwork is supposed to work this way.
But unless we're talking about splitting the mailing list into a bunch
of mini mailing lists (like some bug trackers do), it doesn't change
anything fundamental, so I'm not sure why we're discussing this.
I don't follow the bit about splitting the mailing list.
--
emacs -- THAT'S NO EDITOR... IT'S AN OPERATING SYSTEM!
From: Eric Wong <hidden> Date: 2016-06-15 22:54:20
Michael G Schwern [off-list ref] wrote:
On 2012.7.24 7:55 PM, Eric Wong wrote:
quoted
Except git is also a "new specialized tool". Your examples are exactly
why I'm saddened many projects only adopted git, but not the workflow
which _built_ git (and Linux).
Github also has broad spectrum utility. I learn how to fork and work with a
Github pull request once, and I can repeat that on thousands of different
projects of all different sorts of things.
This commonality of tools and techniques is very important to easing the on
ramp for new (to-your-project) developers.
I agree commonality is important.
But to me, it's not worth the cost of reliance on centralized,
single-vendor solutions. My distrust and dissatisfaction with
centralized/single-vendor solutions is the reason I'm involved with Free
Software (and decentralized version control) in the first place.
quoted
Email is integral to Free/Open Source development and remains one of the
few things on the Internet not (yet) controlled by any central entity.
Once setup, the same email setup can work across all projects which use
email. These projects need not be hosted on the same websites/servers
at all.
While I hear your concern about being centrally controlled, it is largely
irrelevant to the new user experience. And remaining independent does not
mean you can't use web tools. Be wary of a false dichotomy between Free and web.
Of course, I'd be in favor of shifting development to something less
centralized than a mailing list. OStatus may become a good choice one
day, but the adoption/tools just aren't there right now.
"We use a mailing list" is by no means an indication of commonality. Every
project of the "send patches to the list" form has their own quirks and ways
of doing it. Usually they're not written down. This is what I've been
struggling with. I've been sending patches to mailing lists for decades and I
can tell you everybody does it differently. "Send a patch to the list" is one
of the steeper project on-ramps.
Sure, every project/culture has different norms. It's no big deal,
learn them, or avoid them.
Projects all have different coding styles, different conventions for
writing commit messages, changelogs and so on... I live with that and
I'll do my best to adjust my style/editor settings/grammar/vocabulary
accordingly for each project I contribute to.
I won't send patches to mailing lists of projects which prefer
patches/pull-requests on their web tracker, either. If the project is
important enough to me, I'll (grudgingly) use whatever tools/formats the
maintainers prefer.
quoted
How about we educate users about a proper email setup instead? If
they're capable of learning git, they're surely capable of setting up an
email client properly, and perhaps more projects can adopt an
email-centric workflow.
SubmittingPatches would be helped by that, particularly with a clear
step-by-step example of using git-send-email and all its numerous command line
switches.
It's documented in the gitworkflows(7) manpage. They should probably be
linked somehow.
And, finally, the last thing most people want is more email. Seriously. It
sounds like you live in your mailer, but fewer and fewer people do that. Me?
I don't want to join another mailing list. My email management is a disaster!
I live in my mailer/$EDITOR/shell and I'm happy with that.
The last thing I want is more cookies, non-Free JavaScript code, logins,
user tracking/profiling, memory/CPU usage. I doubt either of us will
get what we want, though :<
What it comes down to is this: is it enough to contribute to git.git to know
how to work on git.git? Or do you also need to live in your mailer? Bolt on
that extra requirement and you lose a large swath of contributors.
We need to use something. Right now our choice of mailer is the best
choice for _existing_ contributors.
quoted
For me, the whole social network followers/timeline thing also has a
_huge_ creepiness factor to it. How one prioritizes and spends time
between different different (especially unrelated) projects should be
nobody else's business.
I don't make it /easy/ for someone (e.g. Junio) to know I'm slacking
off on my git work to hack on ProjectNoOneUses :)
You want to know what's creepy? That you'd think people work like that.
It doesn't work out that way. People have far better things to do than stalk
your Github commits to see how you're spending your time. You're just not
that interesting. Neither am I!
(If I really wanted to I could just compile your activity from public list
archives and repositories, so you're really not broadcasting any less
information about yourself by staying off Github. But I wouldn't want to,
because you're just not that interesting and I have better things to do with
my time!)
There's a big difference between making information easy-to-access vs.
merely possible-to-access.
For the most part, people don't care about me (which I'm glad for), but
it has creeped me out when somebody did (especially people I've never
interacted with before). People do often look to other well-known
developers as role models and GitHub's made it easier for folks who
welcome that attention.
quoted
quoted
If all the clicking and opening tabs in a browser feels uncomfortable to
you... its something you learn like anything else. Less and less people are
comfortable in mail clients. Who is the system optimized for? It doesn't
have to be a zero sum game.
(Still not speaking for others) I believe GUIs are (mostly) harmful.
You can hate GUIs, but you should also realize that just about everyone out
there likes them, and they're not all morons. If you deny GUIs as a tool for
git.git developers because of your blind spot, then you're losing potential
contributors. More and more as time goes on.
I disagree, there's a healthy number of users learning to do more and
more on the command-line. There'll likely always be more GUI users, but
the command-line isn't going away.
Recognize it as a personal blind spot, don't punish your users because of it.
Users of my software are already command-line users.
I'm certain of this because I don't develop GUI software :)
quoted
Graphical browsers don't interact well with command-line tools.
Browsers have no concept of a working directory; I can't fire up a
browser tab/window for each project I work on and edit/apply patches
directly from the browser like I can with an MUA.
I'm not sure what you're talking about, or what sort of workflow you've got
going with your mailer, but I'm sure with just as much time and effort as
you've put into your CLI and MUA setup you can be just as efficient or moreso
GUI. One can do crazy shit in browsers these days either in Javascript or by
writing or using an add-on. But also, one doesn't have to do EVERYTHING with
a single tool. Amazing But True!
I run my mailer from different machines which I usually control remotely
(on links insufficient for X11 forwarding, but enough for regular
ssh/mosh).
I write email/code with my $EDITOR of choice, and can pipe messages from
my mailer to arbitrary command-line programs (e.g. git am, patch, ssh).
My mailer lets me edit patches/commit messages as needed (fixing minor
grammar/spelling mistakes, adding Acked-by/Tested-by/Signed-off-by:
lines) before piping them. I use multiple tools, but I can do all this
without the overhead of switching terminals/windows (which can cause a
loss of mental focus).
A web browser is significantly clunkier and would require extra
steps/tabs/windows to put/run code where I want it.
One could develop/improve CLI programs for a REST API, too, but
right now that API is still owned and controlled by a central entity.
If the web-based API weren't centrally controlled, I'm not opposed to a
workflow which allows me to interact with the API via curl or
purpose-built CLI tools (with offline capability).
You should consider sitting down with somebody who works very differently from
how you do and see how they do it. You might learn something you don't know
you don't know!
Sure I've tried, but I have yet to be impressed by anything I've seen
from GUI users. On the other hand, I have learned much from other
command-line users over the years (and developed my own workflows this
way).
And again, it *does not have to be zero sum*. It doesn't have to be email VS
GUI. You can have your cake and eat it too.
I agree we can do both, but we already have email.
I think the git project endorsing any /workflow/ based on a centralized,
non-Free service would be damaging to the viability of Free,
decentralized version control.
From: Michael G Schwern <hidden> Date: 2016-06-15 22:54:20
On 2012.7.25 4:48 PM, Eric Wong wrote:
We need to use something. Right now our choice of mailer is the best
choice for _existing_ contributors.
I believe this entire discussion can be reduced to that right there.
If your process is optimized for existing contributors, it will work well for
existing contributors, who will want to optimize it for themselves. Repeat.
If the main way you evaluate your process is asking "is this more convenient
for me" then you're probably in that spiral.
This creates a process very well tuned to the existing contributors, and its
very convenient for them. But the consequence is it becomes more and more
work for a new contributor to join.
Before talking about anything else, the existing contributors have to ask
themselves a simple question: Do we care about getting new contributors?
The answer can be "no" ("yes, but not if I'm inconvenienced" is a no). Maybe
you're happy with the people you've got. But there's no point in getting into
detail until that's settled.
That's mostly a rhetorical question. I want to wrap up the meta-discussion
and focus on getting patches in.
--
100. Claymore mines are not filled with yummy candy, and it is wrong
to tell new soldiers that they are.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:54:20
Michael G Schwern wrote:
Do we care about getting new contributors?
Not if the cost is too high, no. I personally do think it is
important to make life easy for new contributors, not because that
will somehow compel them to work for me for free, but because it's a
kind thing to do.
Does that mean that I'm going to start reviewing patches submitted as
virtual pieces of paper in Second Life if that is what is most
convenient for potential new contributors? No way. If I felt
compelled to do that, I'd become grouchy, and grouchily spending time
indulging people out of a perverse sense of obligation is not a kind
thing to do.
Jonathan
From: Eric Wong <hidden> Date: 2016-06-15 22:54:20
Michael G Schwern [off-list ref] wrote:
On 2012.7.25 4:48 PM, Eric Wong wrote:
quoted
We need to use something. Right now our choice of mailer is the best
choice for _existing_ contributors.
I believe this entire discussion can be reduced to that right there.
If your process is optimized for existing contributors, it will work well for
existing contributors, who will want to optimize it for themselves. Repeat.
If the main way you evaluate your process is asking "is this more convenient
for me" then you're probably in that spiral.
This creates a process very well tuned to the existing contributors, and its
very convenient for them. But the consequence is it becomes more and more
work for a new contributor to join.
The process is _not_ a lot of work. At least no more than any other
project: observe the regulars -> imitate the regulars
Many/most regular git contributors are not Linux kernel developers, yet
were able to quickly able to get up-to-speed with git. AFAIK, the Linux
kernel gets plenty of new contributors every year, too.
Before talking about anything else, the existing contributors have to ask
themselves a simple question: Do we care about getting new contributors?
Yes, if contributors are willing to learn/respect existing conventions.
We do take time to help new contributors out :)
For me, it's certainly "no" if there's any endorsement of
non-Free Software or centralized/commercial services involved.
The answer can be "no" ("yes, but not if I'm inconvenienced" is a no). Maybe
you're happy with the people you've got. But there's no point in getting into
detail until that's settled.