New 1.14 RC date?

[Stephen J. Turnbull]

Andrew Bennetts writes:

 > Apologies for snipping and thus ignoring much of your reply, but I think
 > most of the points I'd make have already been made in this thread at once
 > already.

The only point that you snipped that I'd like to see discussion of is
my off-the-cuff guess at what the release cycle should look like, and
specifically, that a feature should land *early* in the cycle rather
than right before rolling the distribution media.

 > My point here, which you seem to have missed, is that "ready for
 > release" has several inputs,

No, I didn't miss it.  I'm deliberately ignoring it because you're
absolutely right, but it's irrelevant to my point.  My point, which
you may have missed, is that I am delegating that *technical*
judgment[1] to the contributor of the code, who presumably is taking
those inputs into account.

My understanding (which may be mistaken) is that some Brisbane core
proponent requested a delay (or supported one suggested by somebody
else), because that would allow them to land a feature that otherwise
*could not be done* for this release.  Their judgment, not mine.

 > You also say further down that you "have no opinion" on whether
 > this is actually a risky landing, which seems at odds with your
 > absolute certainty here that it's not ready to be in the release.

It's not "my" certainty.  I'm playing the role of project manager, who
has some technical experience but doesn't have his hands on this
particular feature.  (And in the real Bazaar development process,
that's trivially true!)  So it's "certainty" according to those who
requested the delay, or are taking advantage of the delay, to land a
feature that otherwise wouldn't have landed.  As a manager, that
raises red flags for me immediately.

 > > Let me take a hack at it.  It's *developer-centrism*.  "Gotta get
 > > mine in."  That's really what the developers are saying.  "It's
 > > good enough for us."  But releases are for users, not for
 > > bolstering developer ego.
 > 
 > I'm hoping you didn't intend that paragraph to be insulting, but
 > it's hard not to read it that way.

I know.  I've worked with enough developers.  But there's hardly any
other way to say it: "you're human, you know" is trite and hardly
specific enough.

 > I can assure you, as a developer, my driving motivation is making sure we
 > make the best tool for our users as we possibly can.  I don't have any
 > special insights into anyone else's thought processes, but I expect the
 > other developers feel the same way.

"The road to Hell is paved with good intentions" seems apropos here.

Of course that's your motivation, but developers are people too, just
as capable of kidding themselves about the value of their work as
anyone else.  In my experience, hackers are about as optimistic about
their own product as they come.  "Let's get this in, the users will
love it."  Now, most of the core Bazaar developers are professionals
(ie, employed to work on the project), and both by incentive and by
selection probably have a more objective view than the typical hacker.
But ... that was true of the teams that Fred Brooks wrote "The
Mythical Man-Month" about, too.

 > Or if that doesn't reassure you: happy users bolster my ego, and unhappy
 > users deflate it.  It's simply not in my interest, or my ego's interest, to
 > have a bad release.  Not even in the service of a hopefully better one down
 > the track.

Strawman.  Of course you don't have a stake in producing a bad
release.  But people, and developers are people, are very much capable
of being excessively optimistic about the probability of success and
the size of the damage if something does go wrong.  And they tend to
completely discount any damage to the process itself.

A one-month release cycle is extremely ambitious.  The Bazaar team has
done an excellent job of keeping to that schedule so far, but it's
only been a half-dozen or so, right?  But it's human nature to
overvalue the product, and undervalue the plan (process) that produced
it.  Maybe a release per month was too ambitious.  What I'm saying is
that you won't know until you try it.

AIUI, this is your first real test.  You have an important feature
that should have just missed the window, and now you have a chance to
rush it in.  So you do.  What does that say about your evaluation of
the value of the process and the one-month schedule?

"Special cases aren't special enough to break the rules."  Are they?


Footnotes: 
[1]  I was a release manager before I was a major code contributor.
I'm used to delegating technical judgment. :-)