Bazaar 2.1.0b3 what to do?

Sun Nov 8 01:11:46 GMT 2009

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

Martin Pool wrote:
> 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.

Sure. Though one could consider this email "anyone know of something
that should be updated in the bug tracker?"

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

That's fine. for whatever reason it wasn't clear to me that it was the
official policy. Hence the question.

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

I did manage to get all of 2.1.0b2 built, and was thinking to possibly
announce on Friday, but ran out of time. So for now, I think I'll just
do 2.1.0b3 on ~Monday, and not worry about a 2.1.0b2 announcement. (And
then I'll probably just announce 2.0.2 + 2.1.0b3.)

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

Sure.

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

iEYEARECAAYFAkr2GtIACgkQJdeBCYSNAAMuwQCffqO9wNO/9rWxY+2zOQ3gTC9x
y6cAn3quJIdnBHurzjeY4NHXSmWZ9WVQ
=fWmv
-----END PGP SIGNATURE-----