Differences between revisions 5 and 6
Revision 5 as of 2014-10-02 17:30:02
Size: 2677
Editor: Ry4anBrase
Comment: wrong case on link
Revision 6 as of 2015-06-09 17:32:05
Size: 4195
Editor: AugieFackler
Comment: Significant edits to try and make the page less unwelcoming to newcomers.
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Do you really want to argue with me about X? =
As Mercurial project leader, I'm continually called upon to revisit questions about design choices, style choices, project procedure, and so on.
= I'm weary of this topic =
Line 4: Line 3:
Unsuprisingly, many of these topics have been discussed in great depth in the many years since the project began. But they regularly reappear as new people join the community. Thus, a rather alarming fraction of my time is spent recapping discussions that have already occurred or bluntly directing people to visit the [[MailingLists|list archives]]. As Mercurial project leader, I'm continually called upon to revisit
questions about design choices, style choices, project procedure, and
so on.
Line 6: Line 7:
Many of these questions are also ''moot'': the relevant decision was made many releases ago and now can't be unmade without breaking [[CompatibilityRules|backward compatibility]], which I am absolutely loathe to do. So not only is it time-consuming for me to reply to, it's also guaranteed to be a purely academic discussion that might be fascinating for you but just tedious for me. Unsuprisingly, many of these topics have been discussed in great depth
in the many years since the project began. But they regularly reappear
as new people join the community. Thus, a rather alarming fraction of
my time is spent recapping discussions that have already occurred or
bluntly directing people to visit the [[MailingLists|list archives]].
Line 8: Line 13:
Among the various decisions that aren't moot for the above reasons, I'm still deeply uninterested in revisiting many of them because it's not a good use of time. There's an infinite amount back-and-forth that can be made about any given topic of interest, but time is a scarce resource so at some point it makes sense to make a decision and stick to it and refuse to waste any more time on it. Many of these questions are also ''moot'': the relevant decision was
made many releases ago and now can't be unmade without breaking
[[CompatibilityRules|backward compatibility]], which I am absolutely
loathe to do. So not only is it time-consuming for me to reply to,
it's also guaranteed to be a purely academic discussion that might be
fascinating for you but just tedious for me.
Line 10: Line 20:
Every project choice also means I have to say "no" to someone. This part of my job is really unfun, but it's also unavoidable. ''Please'' don't make me do it more often or forcefully than necessary. Among the various decisions that aren't moot for the above reasons,
I'm still deeply uninterested in revisiting many of them because it's
not a good use of time. There's an infinite amount back-and-forth that
can be made about any given topic of interest, but time is a scarce
resource so at some point it makes sense to make a decision and stick
to it and refuse to waste any more time on it.
Line 12: Line 27:
Some of the most well-worn topics include: Every project choice also means I have to say "no" to someone. This
part of my job is really unfun, but it's also unavoidable. ''Please''
don't make me do it more often or forcefully than necessary.

== Topics that are ''moot'' because of [[CompatibilityRules|backward compatibility]] ==
Line 15: Line 34:
 * copy/rename semantics
Line 17: Line 37:
 * copy/rename semantics
== Topics where we've worked out a solution that is in some stage of progress ==
Line 19: Line 41:
 * turning color/pager on by default  * turning color on by default
   * color should move to core, then this might be an interesting discussion
 * turning pager on by default
   * pager still has rough edges [[http://thread.gmane.org/gmane.comp.version-control.mercurial.devel/64217/focus=64276|around aliases]] and other corners
   * It seems that as many users are staunchly opposed to pager as are strongly in favor of turning it on

== Topics which are technically infeasible, or would introduce more complexity than I'm willing to accept ==
Line 22: Line 51:
   * Our format wasn't designed to be machine-editable, so performing
     edits without corrupting existing files isn't necessarily
     feasible.
   * Programmers are the primary market for Mercurial, and a
     programmer who is uncomfortable with a text editor is roughly
     like a surgeon that is uncomfortable with a scalpel.
 * [[MercurialApi|internal API]] stability

== Other topics (often [[http://black.bikeshed.org/bikesheds]]) ==
Line 23: Line 62:
 * [[MercurialApi|internal API]] stability    * better tools are welcome, but at present reviewer time is ''by
     far'' the scarce resource for the project, so optimizing for
     those who are ''performing reviews'' is the current optimization
     priority
Line 25: Line 67:
   * Some volunteers ''are'' tinkering with this, but it's not a priority.
Line 26: Line 69:
 * basically anything to do with Git (aka "omg fml")  * Asking about a Git feature (aka "omg fml".)
   * It turns out the author of Mercurial has very limited experience
      with git, so you're better off describing what you'd like to do
      in plain English.
Line 28: Line 74:
(And if I've directed you here, your topic too!) (And if I've directed you here, your topic fits into one of those categories!)
Line 30: Line 76:
Finally, if you really want to change my mind about something (very rare but not impossible), you'll need to convince me that you've read all the past discussion on the topic and have something actually new and important and non-obvious to say about the topic. If you instead choose to argue by persistence or appeal to numbers/n00bs/git, I'll probably just wish you luck on your fork of the project and get back to work. Finally, if you really want to change my mind about something (very
rare but not impossible), you'll need to convince me that you've read
all the past discussion on the topic and have something actually new
and important and non-obvious to say about the topic. If you instead
choose to argue by persistence or appeal to numbers/n00bs/git, I'll
probably just wish you luck on your fork of the project and get back
to work.

I'm weary of this topic

As Mercurial project leader, I'm continually called upon to revisit questions about design choices, style choices, project procedure, and so on.

Unsuprisingly, many of these topics have been discussed in great depth in the many years since the project began. But they regularly reappear as new people join the community. Thus, a rather alarming fraction of my time is spent recapping discussions that have already occurred or bluntly directing people to visit the list archives.

Many of these questions are also moot: the relevant decision was made many releases ago and now can't be unmade without breaking backward compatibility, which I am absolutely loathe to do. So not only is it time-consuming for me to reply to, it's also guaranteed to be a purely academic discussion that might be fascinating for you but just tedious for me.

Among the various decisions that aren't moot for the above reasons, I'm still deeply uninterested in revisiting many of them because it's not a good use of time. There's an infinite amount back-and-forth that can be made about any given topic of interest, but time is a scarce resource so at some point it makes sense to make a decision and stick to it and refuse to waste any more time on it.

Every project choice also means I have to say "no" to someone. This part of my job is really unfun, but it's also unavoidable. Please don't make me do it more often or forcefully than necessary.

Topics that are ''moot'' because of [[CompatibilityRules|backward compatibility]]

  • branches/tags/bookmarks design choices

  • copy/rename semantics
  • diff vs diff --git
  • diff/status vs merge semantics

Topics where we've worked out a solution that is in some stage of progress

  • unicode on Windows (see WindowsUTF8Plan and EncodingStrategy)

  • turning color on by default
    • color should move to core, then this might be an interesting discussion
  • turning pager on by default
    • pager still has rough edges around aliases and other corners

    • It seems that as many users are staunchly opposed to pager as are strongly in favor of turning it on

Topics which are technically infeasible, or would introduce more complexity than I'm willing to accept

  • invertible hgignore rules

  • changing config file settings from the command line
    • Our format wasn't designed to be machine-editable, so performing
      • edits without corrupting existing files isn't necessarily feasible.
    • Programmers are the primary market for Mercurial, and a
      • programmer who is uncomfortable with a text editor is roughly like a surgeon that is uncomfortable with a scalpel.
  • internal API stability

Other topics (often [[http://black.bikeshed.org/bikesheds]])

  • using email for code review (remember, I have a huge stake in this topic)

    • better tools are welcome, but at present reviewer time is by

      • far the scarce resource for the project, so optimizing for those who are performing reviews is the current optimization priority

  • Python 3 (see SupportedPythonVersions)

    • Some volunteers are tinkering with this, but it's not a priority.

  • various CodingStyle choices

  • Asking about a Git feature (aka "omg fml".)
    • It turns out the author of Mercurial has very limited experience
      • with git, so you're better off describing what you'd like to do in plain English.

(And if I've directed you here, your topic fits into one of those categories!)

Finally, if you really want to change my mind about something (very rare but not impossible), you'll need to convince me that you've read all the past discussion on the topic and have something actually new and important and non-obvious to say about the topic. If you instead choose to argue by persistence or appeal to numbers/n00bs/git, I'll probably just wish you luck on your fork of the project and get back to work.

mpm/moot (last edited 2016-10-06 12:04:00 by rcl)