Re: display-buffer-alist simplifications

[Eli Zaretskii <eliz@gnu.org>]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: juri@jurta.org,
>     rudalics@gmx.at,
>     cyd@stupidchicken.com,
>     emacs-devel@gnu.org
> Date: Fri, 29 Jul 2011 10:39:42 +0900

First, let me make it clear that what I wrote earlier and what I will
write in the future in this thread is by no means meant to be a
criticism of Stefan's and Chong's style of leadership.  I have nothing
but deep respect for their work.  In my case, wrt the bidi support,
their constant encouragement to push this through and get the code
merged onto the trunk and into Emacs 24.1 was definitely a great help.

IOW, I don't intend to say that the current maintenance team does not
do well what I think it should do.

>  > You will most probably disagree, but that's MO.
> 
> I do disagree about policy (I think that it may be a good idea to
> consider merging code like bidi, lexbind, and display-buffer at an
> earlier stage on an explicitly experimental "we're probably going to
> have to take it out, but we need to know what only the users can tell
> us for future work" basis), but how is that "disrespectful"?

If there's considerable doubt about the usefulness and/or quality of
implementation or UI aspects of such a feature, that doubt should be
eliminated to the large extent while the feature is still on a branch.
Most large features like this underwent this process to some degree,
and that is fine.  Once the merge happens, the decision to revert
should be the last resort, not part of a "trial-and-error" routine of
some kind.

In my case, I worked for 2 years on bidirectional display.  That
involved a lot of effort, sometimes at considerable personal price.
Telling me now that this will be reverted _will_ have certain
unpleasant effects on my mood, to put it mildly.  If someone would
request me to do that, I will have a moral right to ask where were
they for the past year and a half, since the bidi code was merged onto
the trunk, and why didn't they take a good look at it, try it out, ask
questions etc.  If I did a poor job, I'd like to hear that back then,
and cut my losses, or go back to the drawing board and come up with a
better design or implementation.

I don't know how long it took Martin to do what he did with
window-level display features, but I'm certain it was longer than a
day or a month.  I don't remember how long was the code available on a
public branch, but it wasn't a day or a month, either.  I expect
Martin to have similar feelings about reverting it now.  I think I
already saw an expression of these feelings in his messages lately.  I
don't think we should trigger such feelings, except if that's the only
way to prevent some disaster.

IOW, developing software by volunteers is a social process, no less
than it is a technical or managerial one, I'm sure you know that.
Reverting some significant contribution is not just a technical
decision, because it has profound social and emotional consequences.

More generally, the GNU Project's goal is to make a better world, not
just better software.  You cannot get there by disregarding people you
meet on the way, just because that might make maintenance or
"progress" a tad harder.  But I digress.

> Note that I didn't propose that people discount the maintainers'
> considered opinions, only that they not argue against reversion simply
> because it means changing code that's been approved.  IMHO it's more
> disrespectful to suggest that the maintainers can't change their minds!

I wasn't talking about just _any_ code reversion, we do that all the
time.  I was talking about significant features that took a long time
and a significant effort to implement and tune, and that had been
publicly available for quite some time.  When we are past a certain
quantity of effort, there's a need for a qualitatively different
decision-making process regarding reversion, IMO.

> Anyway, the word "experiment" is appropriate until you propose a more
> accurate one that takes into account both the maintainers' approval
> and the uncertainty of success.

The point is that certainty of success should be quite high as a
prerequisite for approving such significant features for a merge.