keyword expansion and post_commit hook in 2.0 (was Re: DRAFT 2.0.0 ANNOUNCEMENT)

[Stephen J. Turnbull]

Martin Pool writes:

 > But the change (4600 on bzr.2.0) really is just adding a hook and
 > calling it, and I think it is reasonably safe.

All I'm saying, and I repeat it, is that

 > > I think you vastly underestimate just how picky such users can be.
 > > You're running a substantial risk with little gain that I can see.

I'll add that the risk is losing the trust of a vocal group of users.
And since the effect of this change will manifest as an unexpected,
bzr-induced change in a file, I don't think they'll be quiet about it.

A second important risk is that there is another vocal group of users
(actually, many of them) who will use this as a precedent for lobbying
for their own little tiny reasonably safe changes.  XEmacs had two
brownbag releases early in the 21.4 series, one of which was due to
programmer arrogance, but the other was due to me bowing to exactly
that kind of pressure to add many individually small changes.  One of
them blew up....

IME, having a "no tolerance" rule is much easier to enforce than a
"rule of reason" where the advocates have a much better idea of the
risk factors than I do, but they put on rose-colored glasses.  After
the disaster the litany is "but I didn't know, how could I?"

 > Actually 2.1.0 is scheduled for February next year
 > <https://edge.launchpad.net/bzr/+series> but 2.1.0b1 is next week.  So
 > any changes we decide not to merge to 2.0, will be available to people
 > in a beta release within a month, but only in a six-month release in
 > up to six months.

I see.  That's a longer interval than I thought it was, but I would
suggest in cases like this that you float the notion that users could
use beta 2.1 or wait until February (if they're already using the
feature, then they're using betas or perhaps a locally patched bzr.dev
now, and if not, the chance that waiting a few months for this feature
would be terribly painful is low enough that it's worth asking them).