Bazaar 2.1.0b3 what to do?

[Martin Pool]

2009/11/6 John Arbash Meinel <john at arbash-meinel.com>:

> So thanks to Martin we have discovered a "Critical" regression for
> Bazaar 2.1.0b2, namely the new proxy code is incompatible with python
> 2.4. Vincent has a fix for it, which I'm trying to land into at least
> bzr.dev, though I'm running into problems with codehosting right now.

for the benefit of the tape, <https://bugs.edge.launchpad.net/bzr/+bug/475585>

> Anyway, once that lands into bzr.dev, we have a question to answer.
> Namely, how do we want to do bzr 2.1.0b3. We settled on a policy that we
> won't do RC's for the beta releases, instead we'll just release the next
> one early if there is a regression.
>
> Which is fine, but the questions I have are:
>
> 1) Are there any other regressions that we should target for 2.1.0b3? I
>   don't really want to release 2.1.0b4 the next week.

Others may know of things they want to raise, but there are no other
critical bugs <https://bugs.edge.launchpad.net/bzr/+bugs?search=Search&field.importance=Critical&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed>

I think generally speaking we shouldn't stall saying "maybe there's
something we don't know about" but rather trust the db and make it
reliable.

> 2) Should we include all changes since 2.1.0b2 that have landed in
>   bzr.dev in the 2.1.0b3 release? Or should we cut a specific new
>   branch directly from 2.1.0b2 and just include this fix?

Our policy is that we'll just do the next beta early, ie directly off
the trunk with whatever else is in there.  I think that still makes
sense here.

The risk of this approach is that there will be cascading bugs, if we
have introduced other as-yet-unknown critical problems between 2.1.0b2
and now.  But, I don't think we should be too shy of that possibility,
and we don't want to commonly be in that situation.

> 3) What to do about the 2.1.0b2 announcement? I still haven't given a
>   public announcement because I still can't build the windows
>   installers. (I'm stuck waiting for the pre-compiled chm files to be
>   built, and that seems to be stalled w/ Ian not feeling well, and
>   Martin trying to take over the doc building.)
>
>   On the plus side, while waiting for that to sort out, I think I've
>   almost got the EC2 host ready for doing the builds, rather than using
>   Kerguelen. It isn't finalized because we still need to sort out
>   building with VS 2008 (either installing the full version, or
>   figuring out how to build tbzr w/ Express edition.)
>
>   I would be okay just skipping 2.1.0b2 as a public release, and only
>   announcing 2.1.0b3 when it is ready. It would just be the first time
>   we've ever done that, so I figured I should check first.

Actually I think we have done that before at least for an rc.

I think that if you don't have the current chm files, you shouldn't
let that block you, but rather you should use the most recent ones you
do have.

> 4) When? I'm thinking early next week, which would mean sorting through
>   some of this at the sprint. Which in some ways is good, though
>   possibly not a great use of sprinting time.

We could possibly make the best of this by doing it in a pair or
larger group to more people able to do this and more understanding of
the issues and processes and problems involved.

So to sum up, either friday or next week,

 make a new b3 from trunk
 put in the latest chm files you have
 announce it

on the whole I'd ask you to put at least some of Friday into thinking
about the sprint and forward-looking stuff rather than just packaging.
 I have felt a bit in the weeds myself in dealing with a bunch of
small things the last two weeks and plan to do the same myself today.

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