[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Preview: portable dumper

From: Matt Armstrong
Subject: Re: Preview: portable dumper
Date: Thu, 01 Dec 2016 01:03:46 -0800

Daniel Colascione <address@hidden> writes:

> On 11/30/2016 08:49 PM, John Wiegley wrote:
>>>>>>> Daniel Colascione <address@hidden> writes:
>>> If that's your decision, I'm going to fork.
>> I'm quite sorry to hear it, but if branches are unacceptable, then such is
>> your right as a free software developer.
> Branches in general are fine. Relegating this specific feature to a 
> branch feels political.
> I would very much prefer to continue improving GNU Emacs. I'm a longtime 
> fan of the GNU Project. But I feel like the current gatekeepers are 
> standing in the way of progress.

Hey Daniel, as a mostly-irrelevant observer, I hope you do.  I don't
have time to devote to Emacs the way you do.  I think the best use of my
time is to try to convince you to continue doing so, by being as honest
as I can.  My advice:

 - take a breath, cool down
 - give it time, build trust
 - build on areas of agreement and common interest

I'm not an Emacs maintainer, and can't speak as one.  But, I play a
similar role at work, and can tell you that the technical issues at play
in these conflicts you have with Emacs maintainers are secondary.  At
their core, these discussions are all about trust.  You don't fully
trust the maintainers, and they don't fully trust you (hopefully "yet"
on both accounts).

In my "day job" I have the equivalent of "commit rights" to some widely
used software critical to the company's function.

>From what I see, the role is similar to that of an Emacs maintainer.  It
is actually more important that the software remain functional and high
quality, and healthy for the long term, than it is to optimize
development practices for velocity of change.

Like Eli, John, and other maintainers, I'm often put in the position of
saying "no" or "slow down, I'm not sure yet" to a change.  Quite often
those asking for the change don't have the same perspective I do.  They
might see their change as minor.  Or critical.  Or urgent.  Or, if what
they introduce incurs some ongoing maintenance cost, they might
underestimate that cost, or truly believe in their commitment to bearing
that cost for the long term.

What they often don't appreciate is that I've seen *all* the failures.
I've seen the "simiple risk free idea" break horribly, or later became
something we regret.  I've seen authors vanish with half finished ideas,
leaving the *actual* maintainers with a mess.  I've seen "critically
urgent" changes become totally unnecessary as easier, more viable
alternatives come to light (often only after careful analysis, done by
me or others, sometimes to the impatient response of those proposing

In this kind of system, where there is a hierarchy of decision makers,
and quality is often more important than speed, trust is earned over

The quickest way to build trust is slowly, with a demonstrated
willingness and capability to collaborate and be sane over a period of
time.  Technical merit and an ability to make good logical arguments are
also important, but secondary.

True technical "arguments" are always boring.  They're pure pro/con
assessments, dispassionately weighing the knowns, unknowns, risks, etc.

Things get "spicy" when it is issues of trust, power, authority,
morality, etc.  Yet, I think it is human nature to try to "win" such
discussions by continuing to appeal to technical issues alone.  Quite
often, it boils down to "I don't trust you yet" and "Your lack of trust
frustrates me".  There is no getting around that.  A decision being made
for "political reasons" is not actually bad, it is the expected norm.

As a mater of political strategy, I'd encourage you to view "please
commit to a branch" as a victory.  Do it and watch trust grow in both
directions.  It is the foot in the door that gets the project closer to
the place you'd like to see it go.  It is a strategic move!

> Let me try one last time to explain my position: this dumping code
> will make no Emacs no worse. It cannot possible destabilize Emacs when
> it is compiled out of Emacs at configure-time. I specifically designed
> this feature to be optional. I am perfectly happy merging my code in
> such a way that it is not compiled into Emacs by default, and I am
> perfectly happy waiting until we've gotten sufficient testing before
> enabling the portable dumper.

First, let me say these your arguments don't strike me as being wildly
off base.  But, I'm not even an Emacs maintainer and can't help but view
the with some suspicion born from the school of hard knocks (see
scenarios outlined above).  Viewed from my experience, if I pretend to
be an Emacs maintainer, this is actually what I end up thinking:

 - There will be more #ifdefs in Emacs code.

 - You are not likely to admit it, but you may disappear.  If you do, it
   may be my job to remove the #ifdefs.

 - You are particularly forceful and invested in getting your way.  If I
   end up saying "no" in the end, you may walk away, leaving me with a
   mess to clean up.

 - You are less experienced than the maintainers with the code base, but
   claim a change is safe/easy/cheap/harmless.  That is nice, but I've
   seen these claims play out differently before.

 - So, risk is non zero.  I'd like to entertain ways to move this
   forward with less risk.

> But because this code is harmless when compiled away and because we
> can back it out without problems, I see the requirement that we put
> this code into a branch as a way to kill the feature. If this code
> were more fundamentally destabilizing, I would feel different --- but
> as it is, since this code is *not* fundamentally destabilizing, I
> don't see a technical case for a feature branch.

The purpose of a branch is to isolate risk.  Sure, any branch may never
merge back, but the primary reason to commit to a branch is to
*facilitate* future code sharing between the branch and mainline, not to
kill features.

>> Just so you know, I'd hope to see your patches on master within six
>> months,
> What specific conditions need to be met before merging?

I think asking for a contract is not unfair, but may be unrealistic.

Have you seen the green light given to the concurrency branch?  That
branch began without a contract.

Again, from a maintainer's point of view, this kind of contractual
question is sometimes unanswerable.  The maintainer may simply feel
reluctance and not know why.

Simply being willing to "play ball" over a period of time, combined with
the absence of any better options coming along, can often tip the scale
in the "okay to merge" direction.  Sometimes people need to actually
"see" a diff on their own screens, run the binary themselves, etc., and
hear a few positive reports from others they trust, before they're
willing to green light something.  Emailing a pre-commited patch around
is one way to do that, but git was invented to support a better workflow

Reluctance on the part of project owners is not inherently bad.

I have actually been in the position of apologizing to people after I
held off their proposed changes for a long time, only to realize that
"they were right all along" and was "obviously the right thing to do" in
hindsight.  I usually thank them for being patient with my reluctance.
In reality, my reluctance is usually good judgment, and has saved more
work than it has caused harm.  Often, I cannot even initially articulate
why an idea gives me pause.  Sometimes it comes to me some time after
the fact.

>> if we can find some willing testers (and one has already stepped
>> forward). The only way your changes *wouldn't* land is if a better
>> alternative comes along in the meantime -- which, of course, would
>> mean we all win.

The above is John saying "yes".  I can't tell you how many times I've
said yes to 95% of a proposal and people walk away because of a minor
difference of opinion on a non-essential issue.

> What is the fundamental difference between merging this code into 
> mainline in a disabled-by-default configuration and merging it into a 
> branch

1) the feature owner (you) absorbs the entire cost of maintaining the
branch.  The maintenance cost at mainline is zero.  There is zero chance
of ChangeLog, documentation, NEWS, or any mention of the feature
appearing in future snapshots, pretests, releases.  As far as I know,
there is no #ifdef for Emacs documentation.  If the feature is not
eventually accepted, the cost of rejecting it is zero.  There is no
"backing the change out" step.

2) it is easy to review the state of the diff in its entirety against
the master at any point.  Once merged you're stuck with more primitive
tools like grep and git blame.

> , except that it's much more convenient to try the feature in the
> former case?

It is probably worth enumerating the concrete differences.

1) git makes it trivial to check out a branch and build.  Playing around
with the concurrency branch was pretty easy the time I did it.  For the
"I want to try this for a day and report back" use case, it is fine.

2) using a feature branch long term *is* harder.  Only one can be used
at a time (easily), and the feature branch owner must merge from master
regularly to keep it relevant.

3) using a branch *combined* with another branch is a pain.  If I want
to test "concurrency AND portable dumper" I have to merge the two
branches myself.

There is no correct choice, they are just simple tradeoffs.  I see both
options as reasonable.

If the goal is to collect a small-ish number of "I tried it on platform
X and it works" reports, and let the ideas percolate/bake for a time,
then a branch makes a lot of sense.

If the goal is to get the feature used by as many different people as
possible as fast as possible in as many different scenarios as possible,
then a branch makes less sense.

I'll point out that your reluctance to commit to a branch is about trust
and not about the technical issues above: you don't seem to believe John
when he says the intent is to facilitate a future merge.

>> I don't suppose I can encourage you to maintain your fork within the
>> Emacs.git repository? There this thing, rhymes with "blanch", where
>> you could work on your version in tandem, even merge changes from us
>> every once in a while... :)
> There have been cries to adopt a more modern development style, one
> focused on GitHub and pull requests. I can certainly accommodate.

I do agree that submitting patches to projects on "non github" systems
is beginning to feel archaic.  I hope the era of emailing patches around

If this is a detractor for Emacs it is also a detractor for every
project hosted on savannah.gnu.org.  Rather than fork Emacs to github to
get the "modern" development style, the greater impact, in terms of
benefit to GNU, is adding the desired features to savannah.

I don't know if anybody is working on this or not.

That said, I think you're too quick to suggest forking Emacs.  You'll
get more done working with Emacs folks than in spite of them, and the
stuff you work on will have more impact.  Even if it feels to you like
you could go 10x faster alone, building a real community is pretty hard,
and you'd be at high risk of burn out doing it alone, and the final
product may not result in more than another non-standard Emacs that gets
little use.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]