New 1.14 RC date?

Juanma Barranquero lekktu at gmail.com
Thu Apr 2 14:28:43 BST 2009


I'm just a lurker here, coming from Emacs-land, so excuse me (all) for
interrupting.

> Consider the situation though, we have a feature (brisbane-core) that
> we must expose to a wider audience to ensure that it stabilises in a
> more timely and thorough manner than if it remains accessible only to
> the developer core.

Does not worry you stable, regular releases being *the* place to
"expose [beta software] to a wider audience to ensure that it
stabilises"?

> So while you were not suggesting we make builds of bzr.dev, it seems
> to be the implication.

Were not for man-power shortages, that would seem the most logical
procedure, yes. Many projects have stable and beta releases (Python,
to mention one close at hand), so the user can asses how much risk
he's going to accept.

> All advice seems to suggest an expected minimum of risk, and
> developers and non-developer users are suggesting that they would get
> value from a month earlier release.

Much as I understand Jason Earl's willingness to have brisbane-core
ASAP, the Emacs conversion is still an undetermined number of months
away. Stefan, and (I think) Chong, expressed their intention not to
switch to bzr before Emacs 23.X is branched for release.

> I'm concerned at the lack of respect for the users understanding.
> There is no way a user can accidentally use the format and it is
> clearly marked as a development format.

It's not an issue of understanding. Mistakes are made, as the saying
goes. Of course there are multiple ways a user can accidentally use
some format or command he wasn't supposed to. It happens all the time
(not specifically with bzr, but with software at large). You cannot
protect the user against every mistake, but minimizing risks should be
part of the release procedures (or at least, goals).

> This really does come down to an almost religious definition about
> what may be placed in a release.

Defining it as "almost religious" is a cheap shot. It's sticking to a
plan because following the plan has worked in the past, and not doing
so has caused trouble. All in all, why is having brisbane-core in 1.14
and not in 1.15 so important? Emacs is not the reason, so what's the
urgency?

The recent developments (Python developers choosing hg) and the
perception that bzr is somewhat losing the PR race shouldn't press the
bzr developers into rushing things, IMO. If brisbane-core lands in
1.14 (hidden, experimental, whatever) and for some unexpected reason
it causes trouble to users, will the PR backlash be worth the month
gained?

    Juanma



More information about the bazaar mailing list