bzr's development should dogfood format 2a

Possibly we should just delay this until next week when the LOSAs are back. We may get enough test data from Launchpad dogfooding, as they already are.

There is nothing quite like person pain to fix an issue :)

I'd really like to see all the bzr development happening in 2a on Launchpad.

s/person/personal/

I think we should do this this week.

It would be better to do it when 1.17rc1 is in the ppa therefore can be rebuilt/installed on data centre machines; and when it's on Launchpad, because it fixes some bugs we'd otherwise hit.

Me or someone else should talk to a LOSA about it.

There are docs now on doing this; do remember we'll need to coordinate
things to allow time for all branches to be reconciled etc

-Rob

Keybuk tried upgrading a project to 2a today, which was denied because of stacked branches. To me it isn't clear what the way forward is with stacking. Some related bugs:

  plan and ui for upgrading multiple stacked branches: bug #374735
  pushing a 1.9 branch stacked on a 2a branch: bug #393677

Bundles look broken, that doesn't stop upgrading per se but might be problematic with the development process.

  https://bugs.edge.launchpad.net/bzr/+bug/393349

Are there other things that need to be resolved before a bzr.dev upgrade?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wouter van Heyst wrote:
> Keybuk tried upgrading a project to 2a today, which was denied because
> of stacked branches. To me it isn't clear what the way forward is with
> stacking. Some related bugs:
>
> plan and ui for upgrading multiple stacked branches: bug #374735
> pushing a 1.9 branch stacked on a 2a branch: bug #393677
>
> Bundles look broken, that doesn't stop upgrading per se but might be
> problematic with the development process.
>
> https://bugs.edge.launchpad.net/bzr/+bug/393349
>
> Are there other things that need to be resolved before a bzr.dev upgrade?
>

We aren't strictly blocked on bundles, because we've switched to using
launchpad code review for the primary method. (And people who didn't
want to use it because it wasn't open source now have nothing to
complain about.)

However, you should read the doc that Ian wrote up (I believe it is in
doc/*). Basically, you want to push up a *new* branch that is in the new
format, and then start stacking on top of that.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkpnHfUACgkQJdeBCYSNAAPSvwCfcqZuFJwHx7qpqkSVSBjZyqKZ
k/EAnRJJJ3Ut/dYFYmwQWkimR2KxnyJP
=uR73
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John A Meinel wrote:
> We aren't strictly blocked on bundles, because we've switched to using
> launchpad code review for the primary method.

Bundles are the primary way I use launchpad code review. I consider the
bundle breakage a very bad thing.

This also doesn't consider other projects that are using Bundle Buggy.
It doesn't consider other projects that are using bundles generally.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpnI3kACgkQ0F+nu1YWqI2nqQCfVgO+cWd352/uqdUa8IODTwJL
WHwAniop0vT7BGQiouN5kcyr66h9o28M
=ImPH
-----END PGP SIGNATURE-----

John A Meinel wrote:
> Wouter van Heyst wrote:
>
> > plan and ui for upgrading multiple stacked branches: bug #374735
> > pushing a 1.9 branch stacked on a 2a branch: bug #393677
>
>
> However, you should read the doc that Ian wrote up (I believe it is in
> doc/*). Basically, you want to push up a *new* branch that is in the new
> format, and then start stacking on top of that.
>

That doc hasn't landed yet - it still in a to-be-reviewed patch.

Ian C.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aaron Bentley wrote:
> John A Meinel wrote:
>> We aren't strictly blocked on bundles, because we've switched to using
>> launchpad code review for the primary method.
>
> Bundles are the primary way I use launchpad code review. I consider the
> bundle breakage a very bad thing.
>
> This also doesn't consider other projects that are using Bundle Buggy.
> It doesn't consider other projects that are using bundles generally.
>
> Aaron

*Other* projects don't cause *bzr* to not dogfood 2a. This isn't about
upgrading everyone, but about upgrading bzr.dev.

I agree, the bundle breakage is *very bad* and is a critical fix that
must be done before we release 2.0. But that isn't what this bug is about.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkpnP/MACgkQJdeBCYSNAAPnfQCgrvS6nZ2J23DB4SuMPUIAOBHe
+I8AoNLl3/dOIM+PuE5bKYYRvPKBRJdQ
=Nkdt
-----END PGP SIGNATURE-----

2009/7/23 John A Meinel <email address hidden>:

> *Other* projects don't cause *bzr* to not dogfood 2a. This isn't about
> upgrading everyone, but about upgrading bzr.dev.

Right.

> I agree, the bundle breakage is *very bad* and is a critical fix that
> must be done before we release 2.0. But that isn't what this bug is about.

Please make sure that bugs that would block other people from
upgrading are targetted to the 2.0 milestone.

--
Martin <http://launchpad.net/~mbp/>

On Wed, Jul 22, 2009 at 03:09:09PM -0000, Ian Clatworthy wrote:
> John A Meinel wrote:
> > Wouter van Heyst wrote:
> >
> > > plan and ui for upgrading multiple stacked branches: bug #374735
> > > pushing a 1.9 branch stacked on a 2a branch: bug #393677
> >
> >
> > However, you should read the doc that Ian wrote up (I believe it is in
> > doc/*). Basically, you want to push up a *new* branch that is in the new
> > format, and then start stacking on top of that.
> >
>
> That doc hasn't landed yet - it still in a to-be-reviewed patch.

Could you point me at the patch? I don't see it in either
+activereviews or on BB, but bzr.dev does have a doc/en/upgrade-guide.

Taking that document as a lead, the approach seems to be to switch the
development focus so that stacked branches can be left untouched.
Do we still need to upgrade stacked branches then?

Wouter van Heyst

Wouter van Heyst wrote:
> On Wed, Jul 22, 2009 at 03:09:09PM -0000, Ian Clatworthy wrote:
>
>> That doc hasn't landed yet - it still in a to-be-reviewed patch.
>>
>
> Could you point me at the patch? I don't see it in either
> +activereviews or on BB, but bzr.dev does have a doc/en/upgrade-guide.
>
>
Sorry - I was talking crap. That patch was approved and landed. (I was
thinking of my smooth-upgrade patch when I wrote that.)

> Taking that document as a lead, the approach seems to be to switch the
> development focus so that stacked branches can be left untouched.
> Do we still need to upgrade stacked branches then?
>
Not completely sure but I suspect not, at least not all of them.

For outstanding reviews say, we may want to upgrade those. After
upgrading the branch locally, just pushing again (with a new name?)
ought to do it.

Ian C.

On Fri, 2009-07-24 at 01:30 +0000, Ian Clatworthy wrote:

> > Taking that document as a lead, the approach seems to be to switch the
> > development focus so that stacked branches can be left untouched.
> > Do we still need to upgrade stacked branches then?
> >
> Not completely sure but I suspect not, at least not all of them.
>
> For outstanding reviews say, we may want to upgrade those. After
> upgrading the branch locally, just pushing again (with a new name?)
> ought to do it.

We hsould be able to just upgrade the trunk in-place, and then upgrade
the branches in-place. Why mess around with extra copies etc that just
have to be cleaned up?

-Rob

On Fri, 24 Jul 2009 13:47:01 Robert Collins wrote:
> On Fri, 2009-07-24 at 01:30 +0000, Ian Clatworthy wrote:
> > > Taking that document as a lead, the approach seems to be to switch the
> > > development focus so that stacked branches can be left untouched.
> > > Do we still need to upgrade stacked branches then?
> >
> > Not completely sure but I suspect not, at least not all of them.
> >
> > For outstanding reviews say, we may want to upgrade those. After
> > upgrading the branch locally, just pushing again (with a new name?)
> > ought to do it.
>
> We hsould be able to just upgrade the trunk in-place, and then upgrade
> the branches in-place. Why mess around with extra copies etc that just
> have to be cleaned up?
>
> -Rob

Because when last checked, upgrading a branch that others are stacked on
breaks the others, and the others can't be upgraded.

On Fri, 2009-07-24 at 02:11 +0000, Tim Penhey wrote:
>
> Because when last checked, upgrading a branch that others are stacked
> on
> breaks the others, and the others can't be upgraded.

This was fixed about 8-9 months ago; I noted when I wrote the draft docs
that we need more testing is all.

-Rob

On Fri, 24 Jul 2009 14:35:44 Robert Collins wrote:
> On Fri, 2009-07-24 at 02:11 +0000, Tim Penhey wrote:
> > Because when last checked, upgrading a branch that others are stacked
> > on
> > breaks the others, and the others can't be upgraded.
>
> This was fixed about 8-9 months ago; I noted when I wrote the draft docs
> that we need more testing is all.
>
> -Rob

Well, no. It doesn't work right now.

On Fri, 2009-07-24 at 02:56 +0000, Tim Penhey wrote:
>
> > This was fixed about 8-9 months ago; I noted when I wrote the draft
> docs
> > that we need more testing is all.
> >
> > -Rob
>
> Well, no. It doesn't work right now.

Are there bugs filed? We have tests that it works.

-Rob

On Fri, Jul 24, 2009 at 03:35:19AM -0000, Robert Collins wrote:
> On Fri, 2009-07-24 at 02:56 +0000, Tim Penhey wrote:
> >
> > > This was fixed about 8-9 months ago; I noted when I wrote the draft
> > docs
> > > that we need more testing is all.
> > >
> > > -Rob
> >
> > Well, no. It doesn't work right now.
>
> Are there bugs filed? We have tests that it works.

I will try upgrading bzr-hookless-email in place today and see how that
pans out.

Wouter van Heyst

On Fri, Jul 24, 2009 at 02:35:44AM -0000, Robert Collins wrote:
> On Fri, 2009-07-24 at 02:11 +0000, Tim Penhey wrote:
> >
> > Because when last checked, upgrading a branch that others are stacked
> > on
> > breaks the others, and the others can't be upgraded.
>
> This was fixed about 8-9 months ago; I noted when I wrote the draft docs
> that we need more testing is all.

This does not currently work.

    bzr upgrade lp:bzr-hookless-email --1.9 # (so I can stack)
    bzr push lp:~larstiq/bzr-hookless-email/390502 --stack
    bzr branch lp:~larstiq/bzr-hookless-email/390502
    bzr check lp:bzr-hookless-email
    bzr upgrade --2a lp:bzr-hookless-email
    bzr check lp:bzr-hookless-email
    cd 390502
    bzr log # tracebacks badly
    bzr upgrade --2a # same thing, ouch
    bzr upgrade --2a lp:~larstiq/bzr-hookless-email/390502 # Revision not present in..
    bzr log # Different Revision not present in.
    bzr branch lp:~larstiq/bzr-hookless-email # The branch lp:~larstiq/bzr-hookless-email/390502 has no revision None.

Safe to say, no, it doesn't work.

I don't know if there are bugs filed yet, I can try to break things up
and file them, but first I'll do a check to see if the recommendation
from the upgrade-guide with unsetting the development focus _does_ work.

Wouter van Heyst

On Fri, Jul 24, 2009 at 06:23:30PM -0000, Wouter van Heyst wrote:
> I don't know if there are bugs filed yet, I can try to break things up
> and file them, but first I'll do a check to see if the recommendation
> from the upgrade-guide with unsetting the development focus _does_ work.

Unsetting the development focus (for the trunk series), pushing up a 2a
version, setting the development focus to that succeeds in not breaking
the branches stacked on the old trunk.

I'm at a loss though on how to upgrade those stacked branches, upgrading
what they're stacked upon first breaks them, upgrading them first breaks
them (though this _might_ be particular to bzr-hookless-email).

Wouter van Heyst

On Fri, 2009-07-24 at 18:23 +0000, Wouter van Heyst wrote:
> On Fri, Jul 24, 2009 at 02:35:44AM -0000, Robert Collins wrote:
> > On Fri, 2009-07-24 at 02:11 +0000, Tim Penhey wrote:
> > >
> > > Because when last checked, upgrading a branch that others are stacked
> > > on
> > > breaks the others, and the others can't be upgraded.
> >
> > This was fixed about 8-9 months ago; I noted when I wrote the draft docs
> > that we need more testing is all.
>
> This does not currently work.
>
> bzr upgrade lp:bzr-hookless-email --1.9 # (so I can stack)
> bzr push lp:~larstiq/bzr-hookless-email/390502 --stack
> bzr branch lp:~larstiq/bzr-hookless-email/390502
> bzr check lp:bzr-hookless-email
> bzr upgrade --2a lp:bzr-hookless-email
> bzr check lp:bzr-hookless-email
> cd 390502
> bzr log # tracebacks badly

This is local? I don't undersand why your local branch is dying. Details
- in a bug please!

> bzr upgrade --2a # same thing, ouch

Same.

> bzr upgrade --2a lp:~larstiq/bzr-hookless-email/390502 # Revision not present in..

Look at the 2.0 targeted bugs; I'm sure this is one of them. If not,
please file a bug.

> bzr log # Different Revision not present in.

This is local, so why is it breaking? More details please.

> bzr branch lp:~larstiq/bzr-hookless-email # The branch lp:~larstiq/bzr-hookless-email/390502 has no revision None.

Your line above doesn't make sense, perhaps you could attach the actual
transcript?

> Safe to say, no, it doesn't work.

I upgraded subunit inplace last weekend with no problems. 'Doesn't work'
is at best an overgeneralisation.

Complex upgrade instructions *will not be followed by everyone*. Lets
fix these bugs.

-Rob

It would also be best if it were possible to upgrade local branches without bzr using more than one or two hundred megs of RAM, preferably in 1-2 hours on a 1GHz machine...

This really shouldn't block releasing 2.0.

Making a 2.0 target again; apparently this list is not just rc bugs.

I'd really like to get this unblocked and try it soon.

Testing the smooth upgrade process is good but testing the code itself may be more important.

Other projects seem to have done ok by making a new branch and switching their trunk to that, so perhaps we should too.

It has begun!