Re: CC Mode and electric-pair "problem".

[Eli Zaretskii]

> From: João Távora <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden,  address@hidden
> Date: Tue, 19 Jun 2018 09:13:10 +0100
> 
> >> > But putting the problematic code on a branch reduces the incentive
> >> > even more, doesn't it?
> >> 
> >> I don't follow.
> >
> > Code on a branch gets less testing by others, and therefore less
> > reminders about the failing test.
> 
> But surely, the programmer who broke the test, who is the person
> technically (and morally) most well suited to fix the problem has the
> all the original incentive to merge his work.

Of course.  But this is not affected by whether the code is on a
branch or on master.

> For me this is very clear: only merge if there are 0 failing tests (or
> rather, if you've increased the number of failing tests by 0).  Perhaps
> CVS used to make this impractival, but nowadays git branches make this
> very easy.

That's a good policy.

> BTW, why does CONTRIBUTE tell us to "make check" at all?

Is this a tricky question?  Because I think the answer is clear to
all.

> >> I would answer "no", assuming the person developing the
> >> temporarily misbehaving code is motivated to do it in the first place.
> >> Develop and break things at will in a branch, merge them to master when
> >> they're clean.  No?
> > If the code is used, its breakage on a branch hurts like it does on
> > master.
> 
> Not at all, no, it hurts only the people interested in trying out the
> feature.  On master it hurts everyone

It hurts those who try the feature on master as well.

> including Hydra's continuous integration, for example, which is the
> issue at hand.  But also other automated things like automated bug
> bisections etc...
> 
> > If it's unused, then what is it doing in the repository?
> 
> To save it.  To show it to others for comments.  This seems rather
> obvious to me, so perhaps we are misunderstanding each other.  I'm also
> pretty sure I've seen branches prescribed in this list for unstable
> features.

OK, I think it's time to stop this dispute.  It isn't going anywhere,
and we basically agree on most aspects of this.