New 1.14 RC date?

Andrew Bennetts andrew.bennetts at canonical.com
Sat Apr 4 06:35:49 BST 2009


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.

Stephen J. Turnbull wrote:
> Andrew Bennetts writes:
>  > Stephen J. Turnbull wrote:
>  > > Andrew Bennetts writes:
>  > > 
>  > >  > However, I don't think it should be left out merely because it is a
>  > >  > beta-quality format.
>  > > 
>  > > "Beta-quality" is irrelevant.  It's *just* *not* *ready*.  That's why
>  > > more time was requested, no?
>  > 
>  > "Ready" for what? 
> 
> It's not ready for release.  Period.  No "for whats" about it.  If it
> *is* ready, you Just Do It.  If you ask for a delay, it's because
> you're not ready.  What's so hard to understand about that?

My point here, which you seem to have missed, is that “ready for release"
has several inputs, and that different people have been using “ready” in
this thread to mean different combinations of those inputs and/or the final
result.  That's made discussion in this thread unnecessarily difficult, and
I've been trying to be very clear about what I'm talking about.  That's why
I asked that question, because it wasn't clear to me exactly what you meant.

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.

> 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 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.

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.

It's true that putting a --development format in a release is not for users
*of that release*, in general.  (In some limited circumstances small groups
of users may benefit, as mysql devs did with the development version of what
became the 1.9 format, but that's secondary.)  It's for users of the
following releases, where the testing that the --development format got
reaps the rewards of the early feedback.  That only works iff the cost to
users of having --development in the current release is practically zero.
Or, if you like, that the risk is no greater than the risk of any other
patch we'd normally commit (the only way to be certain you have no
regressions ever is to never have any changes...).

[...]
>  > What I'm also saying is that:
>  > 
>  >  * maybe it isn't all that risky to land
> 
> I have no opinion on that, except as derived from the request for
> delay itself.

You might find Robert Collin's summary of the changes involved elsewhere in
the thread interesting then.

> It definitely bothers me that a not-yet-dry-behind-the-ears RM who
> doesn't even have his PQM driver's license yet is being asked to

I believe he does have PQM access, actually, and has used it.

> accept any risk at all.  Nothing against Bob Tanner, who I'm sure will
> grow into an excellent RM, and who is already doing a fine job.  I'm
> just remembering the risks I took when I was a n00b RM.  In hindsight,
> it's amazing the project survived.

Our test suite does a good job, and PQM does a good job of enforcing it.
I'm well aware of its shortcomings, but it makes releases a lot less risky
than they might otherwise be.

-Andrew.




More information about the bazaar mailing list