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

[Martin Pool]

2009/9/27 Stephen J. Turnbull <stephen at xemacs.org>:
> 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.

OK, so this is to say that people who have they keywoard plugin
installed and turned on will now see the keywords expanded after they
commit.  Is that the case you're thinking of?

Will anyone see this as an unwelcome change rather than a bug fix?

Any change to that codebase also carries a risk there will be
unintended consequences, but that's a bit different.

> 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?"

I definitely understand where you're coming from because there has
been a lot of (quite understandable, reasonable and well-intentioned)
desire to put more things into 2.0 to make it a really well-rounded
and stable release.  That does directly conflict with wanting the
release to be stable and timely.

But the question is, tolerance for what?

We can fairly easily say: no new formats, no api breaks, no new
features.  However some bugs are on a fuzzy line between whether it's
a bug or a feature, as this one seems to me.

-- 
Martin <http://launchpad.net/~mbp/>