New 1.14 RC date?

[Vincent Ladeuil]

>>>>> "Ben" == Ben Finney <ben+bazaar at benfinney.id.au> writes:

    Ben> Vincent Ladeuil <v.ladeuil+lp at free.fr> writes:
    >> People are aware that this is a development format and that we will
    >> be even more responsive than usual to any problem they may encounter
    >> using it.
    >> 
    >> I even suspect some of them may have already started playing with it
    >> but wait for a more official version before giving feedback.

    Ben> I don't agree with this at all. What ground do you have for stating
    Ben> that “people are aware that this is a development format”?

Because the only way they can use it is by specifying
--development<n> ?

Because there is no way to use it without explicitly requiring
it ?

    Ben> Was that also true of previous development formats that
    Ben> appeared in releases, and if not, what has changed since
    Ben> then?

1.9 for example as been usable as a supported format with
release... 1.9, it think it was available before that as a
development format (see bzr log lp:bzr for details)

Yet, many people have kept their repositories in 0.92 and many
are still using it (I'm sure I still have some branches in that
format waiting for a 'bzr st' to reveal the horror :).

    Ben> Those who are waiting for a “more official” version are,
    Ben> IME, waiting for a “more reliable” version.

I respect that and will never force anyone to use a format they
didn't chose, after all, why having so many formats if you can't
chose ?

bzr is bashed often enough about its myriad of formats, so until
we get One Format To Rule Them All, let's use the feature.

Work on this format has started months ago, many experiments have
been conducted, many conversions have been done successfully,
benchmarks has been conducted several times.

Yet, this work occurred on a dedicated branch while bzr.dev
continued to evolve which means some features had to be
back-ported and we had some regressions. Minor regressions, but
regressions.

Landing in bzr.dev will avoid these regressions because the new
format will be tested as the others for all new features that
lands in bzr.dev just when they land and not a couple of days or
a week later with the associated costs.

The impact on existing features will be zero for people not using
nor wanting to use that new format.

    Ben> Such people are deliberately *not* running a development
    Ben> version so they can be sure that everything they're
    Ben> running is blessed as “release quality”.

Nothing will change for them.

    Ben> Pushing a still-needs-feedback format into a release in
    Ben> an attempt to get it used by such users has *not* worked
    Ben> well in the past,

1) You misunderstood my intent. I don't expect such users to even
think about using that format. It will be publicized as such.

2) I'm not (and no one is) talking about making it a 1.14 format,
whether it becomes an officially supported format is yet to be
decided, it can be 1.15 it can be 1.17, I'm certainly not the one
pushing for that (other do that better than me, so I concentrate
on other things). Once that is reached, it will still take time
to make it the *default* format.

It's only when it become the default format that people who
deliberately don't run development versions will received
warnings about upgrading and they will still be free to *not* use
it.

    Ben> and I see no reason why it would work any better this
    Ben> time.

Are you sure we're talking about the same process here ?

    Ben> If you want to attract more testing and feedback for the
    Ben> format, that is a signal that it needs to stay *out* of
    Ben> the release, IMO, and that instead you should be
    Ben> attracting the type of users who *want* to do such
    Ben> testing of in-development functionality. An official
    Ben> release is not the place to seek such users.

Interesting... What do you propose then ? Leave it available as
it is today in lp:~bzr/bzr/brisbane-core ?

There is no policy defined there, not even a guarantee that this
branch will pass the test suite tomorrow.

Nobody can use it except the devs involved in its development (or
the very brave :).

I'm saying that waiting another month with such a limited user
base doesn't match the actual quality of the format.

I think we need more people to try it, I don't expect a huge
amount of bugs either. I expect feedback about how it behaves for
their projects (presumably better) but *numbers* will tell us.

I think time based releases should just respect the dates and,
except if *critical* bugs are known, they should just be a
snapshot of what is available in bzr.dev at that point in time.

Said otherwise, I'm against delaying time based releases.

I'm also in favor of landing new features early in the release
cycle.

But the case is different here... or may be not, well I think
it's different than adding views for example, because we know for
sure that nothing will change for existing branches in bzr
behavior.

We also know that if the format doesn't land, then surely nothing
will happen either :0)

We started talking (more precisely) about landing brisbane-core
in 1.14 when 1.13rc1 was released, there was still tasks to be
achieved.

Now take a look at http://bazaar-vcs.org/Roadmap/BrisbaneCore
(which needs to be updated, so the situation is better than
painted there).

Do you see critical bugs there ?

Does brisbane-core pass the full test suite as bzr.dev does at
each commit ? For the last revisions: yes.

At that point we have a few options:

- landing in bzr.dev so that we can guard against accidental
  regressions,

- landing in bzr.dev after the 1.14rc1 cut,

- keep working in brisbane-core only.

I don't care that much that we land before or after the 1.14 cut,
but I think we are in position to guarantee compatibility between
that development format and the stable one 1.1[567].

So I think it's time to say to people that runs bzr.dev (at
least): it's dogfood time (and we don't intend that format to eat
your dog either).

        Vincent