Bzr 0.10 release candidate 1

[John Arbash Meinel]

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

Aaron Bentley wrote:
> Gustavo Niemeyer wrote:
>>>> don't think anyone expected that we could.  Martin said:
>>>
>>> Well, I expected.  
> 
> Okay, so clearly we need to manage expectations better.  I'd like to
> find a balance between keeping people informed and getting buried in
> administrivia.
> 
> Already, adding a feature entails
> 1. implementing tests
> 2. implementing the feature
> 3. updating the NEWS
> 4. updating doc/ documentation
> 5. submitting for review
> 6. updating from reviews
> 7. maybe goto 5
> 8. submitting the merge
> 9. updating the spec, if appropriate.
> 
> So you can see why I'd rather not add any more steps.
> 

Actually, it is even worse if you add feature branches and bug tracking.
Which adds:

* Register the branch with Launchpad ('bzr register-branch', or my
bzr_register plugin which provides 'bzr reg'), and associate it with the
bug. This may be one or 2 steps, depending.

* When the bug is fixed in the branch:
  1) update the bug tracker for "Fix Committed",
  2) mark that a fix is available on the given branch.

* When the fix has been merged into bzr.dev:
  1) Change bug status to Fix Released
  2) Go a few layers deeper to change the branch status to Merged.


Launchpad could certainly do some of this if we can get it to track when
a branch has been merged. And then if a branch has been marked as having
a bugfix, it could automatically mark a bug as Fix Released (or
whatever) once that branch has been seen to be merged into the Trunk branch.

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

iD8DBQFE/vFOJdeBCYSNAAMRAmjqAJ9egJ2DJIeG3BxiK5XhOhe/UP4LUgCfWvik
KR0nmrO73g+W8D9D9DHSLGE=
=HWa+
-----END PGP SIGNATURE-----