2.0.3?

Martin Pool mbp at canonical.com
Mon Dec 14 04:30:48 GMT 2009


2009/12/14 John Arbash Meinel <john at arbash-meinel.com>:
> 2.1.0b4 is going to be cut early this week (it is scheduled for Monday).
> I'm wondering if we want to do 2.0.3 at the same time? As near as I can
> tell, updates for the 2.0 series have dwindled quite a bit.
> Specifically, it looks like we have 3 bug fixes:
>
> * ``bzr push --use-existing-dir`` no longer crashes if the directory
>  exists but contains an invalid ``.bzr`` directory.
>  (Andrew Bennetts, #423563)
>
> * Content filters are now applied correctly after pull, merge and switch.
>  (Ian Clatworthy, #385879)
>
> * Improve "Binary files differ" hunk handling.  (Aaron Bentley, #436325)
>
> I suppose that is enough to warrant a 2.0.3. As long as it would be
> enough to warrant a 'backports' for Karmic.

<https://bugs.launchpad.net/bzr/+bug/385879> particular is marked
High, and I think justifiably so, because fixing it will be a big
improvement for people using content filtering.  I think at least
getting that out would be worthwhile.

We could step down to a lower rate after that.  Perhaps it is mentally
easiest to keep them on a monthly cycle and just skip some months for
the stable branch.

It seem to me the biggest problem with releases is getting the
announcement out.  I think this time we should aim to just do it two
days (?) after the source freeze, whether binaries are ready or not.
I think we discussed such a policy before but have not yet put it into
practice.  It might stop it dragging on.

I've been given some tips by james_w on how to get the SRU to move
along and I'll try to do that soon.

> Thoughts?
>
> I also know we have a few patches that were 'borderline' for the 2.0
> series. Are there any of them that we feel justified should be landed
> and released?

Generally speaking having 2.0.x be stable is more important than
having a lot of fixes in it.  But it's worth checking.

In looking at the trunk bug fix section, I see a fair number of things
that, at least looking at the description, really are genuine bug
fixes (as opposed to performance or testing) and that could qualify
for 2.0.  I wonder why they weren't proposed for it?  Like the
following:

* After renaming a file, the dirstate could accidentally reference
  ``source\\path`` rather than ``source/path`` on Windows. This might be a
  source of some dirstate-related failures. (John Arbash Meinel)

* ``bzr ignore /`` no longer causes an IndexError. (Gorder Tyler, #456036)

* ``bzr log -n0 -rN`` should not return revisions beyond its merged revisions.
  (#325618, #484109, Marius Kruger)

* ``bzr merge --weave`` and ``--lca`` will now create ``.BASE`` files for
  files with conflicts (similar to ``--merge3``). The contents of the file
  is a synthesis of all bases used for the merge.
  (John Arbash Meinel, #40412)

* ``bzr mv --quiet`` really is quiet now.  (Gordon Tyler, #271790)

* ``bzr serve`` is more clear about the risk of supplying --allow-writes.
  (Robert Collins, #84659)

* ``bzr serve --quiet`` really is quiet now.  (Gordon Tyler, #252834)

* Fix bug with redirected URLs over authenticated HTTP.
  (Glen Mailer, Neil Martinsen-Burrell, Vincent Ladeuil, #395714)

* Interactive merge doesn't leave branch locks behind.  (Aaron Bentley)

* Lots of bugfixes for the test suite on Windows. We should once again
  have a test suite with no failures on Windows. (John Arbash Meinel)

* ``osutils.terminal_width()`` obeys the BZR_COLUMNS environment
  variable but returns None if the terminal is not a tty (when output is
  redirected for example). Also fixes its usage under OSes that doesn't
  provide termios.TIOCGWINSZ. Make sure the corresponding tests runs on
  windows too.
  (Joke de Buhr, Vincent Ladeuil, #353370, #62539)
  (John Arbash Meinel, Vincent Ladeuil, #492561)

* Terminate ssh subprocesses when no references to them remain, fixing
  subprocess and file descriptor leaks.  (Andrew Bennetts, #426662)

* The ``--hardlink`` option of ``bzr branch`` and ``bzr checkout`` now
  works for 2a format trees.  Only files unaffected by content filters
  will be hardlinked.  (Andrew Bennetts, #408193)

* The new glob expansion on Windows would replace all ``\`` characters
  with ``/`` even if it there wasn't a glob to expand, the arg was quoted,
  etc. Now only change slashes if there is something being glob expanded.
  (John Arbash Meinel, #485771)

* Use our faster ``KnownGraph.heads()`` functionality when computing the
  new rich-root heads. This can cut a conversion time in half (mysql from
  13.5h => 6.2h) (John Arbash Meinel, #487632)

* The launchpad-open command can now be used from a subdirectory of a
  branch, not just from the root of the branch.
  (Neil Martinsen-Burrell, #489102)

These are arguably features not bug fixes, at least for the purposes
of the stable branch:

* ``bzr commit`` now detects commit messages that looks like file names
  and issues a warning.
  (Gioele Barabucci, #73073)

* When launching a external diff tool via bzr diff --using, temporary files
  are no longer created, rather, the path to the file in the working tree is
  passed to the external diff tool. This allows the file to be edited if the
  diff tool provides for this. (Gary van der Merwe, #490738)

and some obviously are performance fixes.

I think there is some risk developers and active users will be on
trunk or betas and therefore not motivated to merge to 2.0.x.  We
should probably ask for bug fixes into 2.0.  I don't feel strongly
inclined to go back and cherrypick things without being requested to.

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



More information about the bazaar mailing list