2.0.3?

[John Arbash Meinel]

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


> * 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)
> 

Possibly worthy of a backport/cherrypick. This was only found during the
test-suite cleanups. So there wasn't an associated bug, just a failing
test or two.


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

Seems like it could, but is probably low impact, and thus not really
worth the effort.

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

This could probably be done, and MySQL may appreciate it? We should
probably solicit feedback on those bugs.


> * ``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)

This was written against 2.0, and only merged bzr.dev to be able to add
a NEWS entry. So easy to backport, but because it changed structures on
disk, I wasn't 100% sure it was worthy...

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

Potentially worthy, but also probably low impact

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

Doc bug, certainly worthy if worth the effort.

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

Similar to 'bzr mv --quiet'

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

Worthy if people care to do it.

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

Worthy if people care

> 
> * 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)
> 

Too many changes. 90% of them are test suite fixes, but it is a fair
amount of churn to worry about.


> * ``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)

I view this is a bit more of a feature-level change.

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

Probably worthy.

> 
> * 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)

Worthy

> 
> * 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)

Not applicable

> 
> * 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)

Feature

> 
> * 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)

Worthy

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

I think our policy is that bug fixes should be started on 2.0 branches.
And then decide whether the level of the change is still 2.0 worthy when
it comes time to land. I've tried to follow that, though I'll admit to
not really pushing to land stuff into 2.0. It is a bit hard to get a
feeling for whether users really need fixes in 2.0 or not.

One thing we might look at, is whether the bug report is reported
against a 2.0 stable bzr. Which would be a good hint that a user is
affected by the bug in 2.0 stable, and thus would benefit from upgrading
to a newer 2.0 stable.

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

iEYEARECAAYFAksmVIEACgkQJdeBCYSNAAOrZACfSYfCG6K0nd3fBiF08V8+cY2y
/u8AoMzdydpy0RFlsyaibJH6FOiVyTBu
=wA+N
-----END PGP SIGNATURE-----