New 1.14 RC date?

Talden talden at gmail.com
Thu Apr 2 22:02:50 BST 2009


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

I'm sorry, I don't buy that.

It has to be possible to express that something is not intended for
production use.  If we can't express this to our users effectively in
the UI, what makes you think we can explain it on the download page -
If we offered 'Bzr 1.14' and 'Bzr 1.15 early access', which do you
think users would download rather often?

I think the UI is a much much better place for us to express this - we
can display warnings when beta content is used, we can prevent default
behaviours from ever touching beta content and make sure that, to even
access beta content (since they need to know the option names to type
them in), the user must have viewed a help page that clearly states
the inappropriateness of using beta content for production use.

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

No.  The plan has been to include development formats - these are beta
quality.  So sticking to the plan is to include brisbane-core, not
exclude it.  The definition of whether this beta content should be in
a release is not some moral absolute.  I stand by my reference to
religion - holding up 'my definition of what a release is' as a moral
absolute is effectively a religious statement.

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

*I* want to be able to evaluate and provide feedback on brisbane-core
to speed it's advance towards production quality - and all indications
are that some others feel the same.  My statements are not coloured at
all by the non-adoption in projects such as Python.  You're right,
they shouldn't rush this in response to the bad PR bazaar has received
- I don't happen to think they are.

--
Talden



More information about the bazaar mailing list