New 1.14 RC date?

[Ben Finney]

Robert Collins <robert.collins at canonical.com> writes:

> I believe you used a rich root format, *not* a development format;
> or if it was a development format, it was the rich root flavourness
> that caused problems.

Andrew Bennetts <andrew.bennetts at canonical.com> writes:

> I'm *guessing* your issue was using a -subtree format, which was
> (and is) a development format, because that's what bzr-svn used to
> require. rich-root formats were made to provide the feature that
> bzr-svn needed without the experimental parts of subtree.

IIRC, I have been burned by both rich-root, *and* subtree, on separate
occasions. One caused unrecoverable data loss, the other “merely”
causes ongoing friction and fallout without necessarily losing data.

The part which makes me so adamant about this issue is that I never
wanted to try *either* of those, since at the time I had no interest
in ‘bzr-svn’ at all; my problems were entirely unrelated (and now
forgotten).


Robert Collins <robert.collins at canonical.com> writes:

> You're enduring the fallout of rich roots, its a serious problem and
> the relevance from it to this discussion is that rich roots were
> added to bzr *before* we'd learnt about making in-development
> features much more clearly 'development'.

I'm not convinced that lesson is learned, if they're to be put into an
official release at all. I reiterate: they should not be there under
*any* name, since when someone in a similar situation to mine at the
time is searching for solutions, it is a grave insult for there to be
a button that accesses a not-release-quality function in the released
product.

Users *have* been lost on this. I was banging on to my whole
organisation about the wonderful testing regime in Bazaar's
development, and that the released code is known to be good quality.
Then, the subtree format blew up, and my data was very visibly (within
that organisation of potential Bazaar users) lost, and over time it
became clear that the loss was irretrievable in my case. Clearly they
have learned from my mistake and will not trust Bazaar with a barge
pole.

This kind of thing, where an in-development feature is available for
use in the released product by a user who is looking for solutions and
pressing buttons confident that the damage can't be *too* bad, *should
not be possible*.

> It sounds like you're trying to help other users avoid running into
> similar problems, and thats good. However as I point out above there
> are two rather different issues here.

I'm not convinced the differences are sufficient to necessitate
muddying the distinction for new users. You can slap as many labels on
development-quality features as you like, but they will be below the
granularity of “I installed the stable release of the software”, and
hence not be seen by users in a hurry.

The perception — justified, I argue — was that I was using code
which had crossed the divide between “not ready for release” and
“ready for release”. I should not need to know more than that in
order to know whether the function I'm about to invoke is ready for
production use or not.

> I think the crux of this discussion may hinge on the definition of
> release quality; and also perhaps on audiences. For various reasons
> we have only one effective channel for getting code to users -
> releases.

The suggestion, made earlier in this thread, to make automated builds
of the development branch, would be a way to address this without
muddying the distinction between release and not-yet-release.


Andrew Bennetts <andrew.bennetts at canonical.com> writes:

> This sounds like a failure of the support conversation rather than
> of the contents of a bzr release. I'm sorry you got bad advice.

As Robert surmises above, I'm arguing here for the sake of other users
who will be in a similar situation in future. The communication error
could easily have been on my side; I may have misinterpreted the
advice.

My point is that *no* misinterpretetation or misunderstanding on my
newbie-in-a-hurry part should even be possible to lead to the
invocation of a not-ready-for-release feature in a released product.
The way to ensure that is to never put such code into a release until
it's considered *ready* for release.

-- 
 \           “We have met the enemy and he is us.” —Walt Kelly, _Pogo_ |
  `\                                                        1971-04-22 |
_o__)                                                                  |
Ben Finney