[MERGE] 1.5? Suppress DeprecationWarning in official releases

John Arbash Meinel john at arbash-meinel.com
Thu May 29 00:21:10 BST 2008

Hash: SHA1

Martin Pool wrote:
| On Thu, May 29, 2008 at 8:00 AM, John Arbash Meinel
| <john at arbash-meinel.com> wrote:
|> | I think the behaviour we want is this (in order):
|> |
|> | 1. If -Wanything is given, stick with what was specified.
|> | 2. For release versions, give no warnings.
|> | 3. Otherwise, warn once.
|> |
|> | I think having no special case for cmd_selftest is acceptable so long
|> | as it can be turned back on by -Werror.
|> |
|> | To do the first I think you will have to look in warnings.filters.
|> The attached patch does this for -Werror. I thought about doing it for
|> - -Wanything, but the problem is that I can't tell the difference between
|> "-Wignore" and someone calling suppress_deprecation_warnings() (which main()
|> will do if someone runs a release bzr).
|> I added tests for everything as well, since I had to work out how to inspect
|> warnings.filters anyway. This doesn't pay attention if someone would do
|> something like "-Wfoo:error" or some other custom handling, but it works for
|> what *we* do as a project, which is enough for me.
| This is still modifying cmd_selftest, and I suggested we should just
| handle -W in the code called from the bzr main routine.  In other
| words it is suppress_deprecation_warnings that needs to be changed.

The attached does what you have requested, and what I wanted. If -Werror is
given, we shouldn't add anything to filters. Otherwise we'll always put in a
- -Wignore for most commands, but override that with -Wdefault for selftest.


Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dep_warnings.patch
Url: https://lists.ubuntu.com/archives/bazaar/attachments/20080528/ab4a7448/attachment-0001.diff 

More information about the bazaar mailing list