Re: Proposal: requiring build peer review for Makefile.in changes
The proposal sounds good to me but I guess you wouldn't want to be notified of every small addition/change to Makefiles in test directories? I suppose you're targeting actual changes to dependencies etc, but where do we draw the line? Can we maybe add a push hook intelligent enough to separate actual changes from minor changes that don't need build peer review by scanning for certain keywords? - Tim On 07/18/2013 02:00 AM, Gregory Szorc wrote: Traditionally, it's been very difficult for the build peers to keep on top of changes in the build config because changes are occurring on bug components we don't follow, are touching files all over the tree, and because build peers aren't always asked for review. The potential for sneaking things past build peer review has resulted in a number of self-inflicted wounds, the Fennec build rules probably being the best example (the dependencies are all wrong and no-op builds take ~16s when they should take 1 or 2s). This history contributed to us implementing a more strict sandbox in moz.build files: take away as many footguns as possible and there will be less self-inflicted wounds. Unfortunately, the moz.build conversion isn't finished and it will drag on for a while. There will still be Makefile.in in the tree and that leaves the door open for new badness. I would like to reinforce the existing policy: *if you are changing a Makefile.in, please ask a build peer for review unless the change is just adding or removing to an existing list.* For the most part, people have been abiding by this policy. However, things are still creeping through. Unfortunately, some of them wouldn't get r+ from a build peer. Since new Makefile.in badness makes people's lives harder (especially when it makes the build slower), I would like to propose a more strict policy around Makefile.in changes: *if a non-list change in a Makefile.in isn't reviewed by a build peer, it doesn't land or gets backed out.* This could potentially be enforced with repository push hooks. I /think/ this proposal is supported by our module governance system since Makefile.in are the purview of the build config module. But I wanted to run the proposal by people to make sure it is generally well-received and there aren't any major concerns. Gregory ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Tim Taubert Firefox Engineer ttaub...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
i2space provide travel portal development at affordable rates
I2space technologies is a leading travel portal development company that provides bus booking software, flight booking software, hotel booking software at very affordable prices. For more details please contact us at 9052266440 / 9704536531 or visit our website http://www.i2space.com/onlinetravelportal.html Contact Person: Bhargava Mobile no. 9052266440 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Mobile Application Software
Mobile Application Software – i2space provides mobile application software for Android and iphone etc. Our apps gives you the best travel mobile application software to all smart phones. For more details visit our website http://www.i2space.com/travel-mobile-application.html or contact us at 9052266440 / 9704536531 Contact Person: Bhargava Mobile no. 9052266440 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using C++0x auto
On Thursday, 18 July 2013 10:32:35 UTC+1, Mike Hommey wrote: On Wed, Jul 17, 2013 at 05:09:22PM +0900, Mike Hommey wrote: On Tue, Jul 16, 2013 at 04:17:50PM +0900, Mike Hommey wrote: On Sat, Jul 13, 2013 at 01:15:31PM -0700, Kyle Huey wrote: We've dropped support for versions of MSVC prior to 2010, and we're requiring at least GCC 4.4. According to [0] that means we should be able to use *auto*. Anybody know any reasons why we can't start using it? Filed bug 894242. (double 42!) This almost stuck, but B2G desktop builds are, guess what, using gcc 4.4, and a bug was already on file to upgrade that (bug 770625). Hopefully this will go forward now that there are patches. And it's now done. Thanks to Ted Mielczarek and Ben Hearsum for the quick reviews, and Aki Sasaki for the buildbot reconfig. Now we can start discussing what specific features we want to start using. Bug 895322 has already been filed to use static_assert instead of MOZ_STATIC_ASSERT. A good resource is http://wiki.apache.org/stdcxx/C++0xCompilerSupport Our base versions are 4.4 for gcc, and 10.0 for MSVC. I'm not sure what our lowest supported version of clang is. From that table, using the gcc and msvc versions, that gives: gcc msvcclang auto4.4 10.0* Yes decltype4.3@10.0@ 2.9 extern template 3.3 6.0Yes new fn syntax 4.4 10.02.9 right angle brackets4.3 8.0Yes r-value references 4.3@10.0! Yes static_assert 4.3 10.02.9 built-in type traits4.3 8.03.0 * v0.9 @ v1.0 ! v2.0 Which means a minimum clang version of 2.9 without built-in type traits, or 3.0 with. - Reece ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: requiring build peer review for Makefile.in changes
On 7/18/2013 2:43 AM, Tim Taubert wrote: The proposal sounds good to me but I guess you wouldn't want to be notified of every small addition/change to Makefiles in test directories? I suppose you're targeting actual changes to dependencies etc, but where do we draw the line? I thought the proposed exception was pretty clear: unless the change is just adding or removing to an existing list. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: requiring build peer review for Makefile.in changes
On 07/18/2013 02:45 PM, Benjamin Smedberg wrote: On 7/18/2013 2:43 AM, Tim Taubert wrote: The proposal sounds good to me but I guess you wouldn't want to be notified of every small addition/change to Makefiles in test directories? I suppose you're targeting actual changes to dependencies etc, but where do we draw the line? I thought the proposed exception was pretty clear: unless the change is just adding or removing to an existing list. Indeed, it was. Sorry, I must have missed that. - Tim -- Tim Taubert Firefox Engineer ttaub...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using C++0x auto
On 7/18/2013 4:32 AM, Mike Hommey wrote: And it's now done. Thanks to Ted Mielczarek and Ben Hearsum for the quick reviews, and Aki Sasaki for the buildbot reconfig. Now we can start discussing what specific features we want to start using. Bug 895322 has already been filed to use static_assert instead of MOZ_STATIC_ASSERT. Bug 895047 and bug 523156 are about changing PRUnichar and jschar respectively to char16_t [wchar_t on Windows], which would eventually give us the ability to do things like stop using NS_LITERAL_STRING().get() for a const PRUnichar *... A good resource is http://wiki.apache.org/stdcxx/C++0xCompilerSupport Our base versions are 4.4 for gcc, and 10.0 for MSVC. I'm not sure what our lowest supported version of clang is. I've generally considered this to be 3.1. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
suggested reviewers for bugzilla products and components
an update was pushed to bugzilla.mozilla.org today which allows us to provide a list of suggestions for the review flag (bug 804708). this list is on a per-product or per-component basis, with the product's suggestions being used in the absence of a component specific list. i have created an initial list on an etherpad using the module owners' wiki page as a source: https://bmo.etherpad.mozilla.org/suggested-reviewers please review and update this document where appropriate. of course per-component suggestions are not perfect - the reviewer should be suggested based on the files being touched in the diff. this is being worked on by mhoye (bug 774145). thanks! -- byron jones - :glob - bugzilla.mozilla.org team - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using C++0x auto
On 7/18/2013 9:44 AM, Ehsan Akhgari wrote: On 2013-07-18 5:32 AM, Mike Hommey wrote: A good resource is http://wiki.apache.org/stdcxx/C++0xCompilerSupport Our base versions are 4.4 for gcc, and 10.0 for MSVC. I'm not sure what our lowest supported version of clang is. As of bug 870173, it's 3.3. I'm hoping that we can follow the latest clang as it's released in the future. That's not the lowest-supported version of Clang (for example, the DXR builds still use 3.2), it's just what the buildbot slaves are using. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: requiring build peer review for Makefile.in changes
I am 100% in favour of this. My only request is that build peers implement something similar to Firefox's catch-all reviewer account, because suggested reviewers won't work for most build changes (the bug won't be filed in Core::Build Config). If I can type :build-peer instead of :gps, it'll even out the load. joe ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: requiring build peer review for Makefile.in changes
On 2013-07-18 10:49 AM, Joe Drew wrote: I am 100% in favour of this. My only request is that build peers implement something similar to Firefox's catch-all reviewer account, because suggested reviewers won't work for most build changes (the bug won't be filed in Core::Build Config). If I can type :build-peer instead of :gps, it'll even out the load. I'll add something comparable to my reviewer-suggesting tool, making sure Makefile.in files are flagged as requiring special attention. If there are other files or classes of file that require that changes to files of type X must get a review by group Y treatment, let me know. - mhoye ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using C++0x auto
On 2013-07-18 5:48 AM, mscl...@googlemail.com wrote: From that table, using the gcc and msvc versions, that gives: gcc msvcclang auto4.4 10.0* Yes Yes, please! decltype4.3@10.0@ 2.9 Yes, please! extern template 3.3 6.0Yes It's not exactly clear to me what the implications of using extern templates are. They promise faster build times. Has anybody tried to use them? new fn syntax 4.4 10.02.9 This seems like it might be useful in some cases, but it also seems like something which should not be overused. right angle brackets4.3 8.0Yes OMG, YES PLEASE! r-value references 4.3@10.0! Yes This is very useful. I believe the JS engine already rolls their own tricks to implement this semantics. static_assert 4.3 10.02.9 Yes, please! built-in type traits4.3 8.03.0 Yes, please! Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: suggested reviewers for bugzilla products and components
On 7/18/13 6:33 AM, Byron Jones wrote: an update was pushed to bugzilla.mozilla.org today which allows us to provide a list of suggestions for the review flag (bug 804708). this list is on a per-product or per-component basis, with the product's suggestions being used in the absence of a component specific list. i have created an initial list on an etherpad using the module owners' wiki page as a source: https://bmo.etherpad.mozilla.org/suggested-reviewers please review and update this document where appropriate. of course per-component suggestions are not perfect - the reviewer should be suggested based on the files being touched in the diff. this is being worked on by mhoye (bug 774145). Nice! Reducing the number of tripping points for new contributors should be a nice win! A number of people use the bzexport Mercurial extension [1] to upload patches from the command line so they don't need to muck about with a browser. It would be awesome to integrate suggested reviewers into that tool. That would require having an API for finding suggested reviewers. Is there an API for accessing this production/component to reviewers mapping? Is it the Etherpad page itself? Would people be interested in adding this metadata to the tree? We could put files in the tree (possibly reusing moz.build files) that identified Bugzilla products/components, modules, reviewers, etc for directories, files, etc and then tools like bzexport could read the data direct from the tree. Presumably most development occurs on or near tip, so there shouldn't be a major versioning concern. This data could be periodically exported to a format Bugzilla could read. We could even have it outputting Mediawiki syntax for managing the modules pages on wiki.mo. I see this solving the problem of mapping directories/files to modules to Bugzilla components to reviewers (we still don't have a machine readable mapping of directories/files to reviewers). [1] https://hg.mozilla.org/users/tmielczarek_mozilla.com/bzexport ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: suggested reviewers for bugzilla products and components
On Thu, Jul 18, 2013 at 9:45 AM, Gregory Szorc g...@mozilla.com wrote: Would people be interested in adding this metadata to the tree? Chromium has a per-directory OWNERS file. We could steal their setup. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: suggested reviewers for bugzilla products and components
On 7/18/2013 12:45 PM, Gregory Szorc wrote: A number of people use the bzexport Mercurial extension [1] to upload patches from the command line so they don't need to muck about with a browser. It would be awesome to integrate suggested reviewers into that tool. That would require having an API for finding suggested reviewers. mhoye is working on this as a mach command. It won't need an API, since it basically suggests the reviewers based on who has previously reviewed code touching the same files. I don't think we should start with a complex system of MAINTAINER files or a bugzilla API unless that system proves to be inadequate. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Possibility of replacing SQLite with LMDB from the OpenLDAP project (or replacing the SQLite backend with LMDB)
On Wednesday, July 10, 2013 8:42:42 AM UTC-7, Marco Bonardo wrote: On 06/07/2013 11:26, Philip Chee wrote: LMDB is an ultra-fast, ultra-compact key-value data store developed by Symas for the OpenLDAP Project. It uses memory-mapped files, so it has the read performance of a pure in-memory database while still offering the persistence of standard disk-based databases, and is only limited to the size of the virtual address space, (it is not limited to the size of physical RAM). It looks like LMDB has speed and size advantages on memory constrained systems like Android and B2G. Ehr, I wrongly replied instead of following-up, let me paste again: As for many other dbms around, comparisons are pretty much hard, just relying on microbenchmarking doesn't help much. What's best, LMDB, levelDB, kyotoCabinet, Sqlite4? It's hard to tell just by looking at these graphs, you'd need measurements done directly on your most compelling use-cases. Just getting those measures is a project by itself. First you need to distinguish SQLite (3 or 4) from the others, which are simply key/value stores. Do you really need complex multi-column tables and complex SQL queries for managing your data? I don't see why; you would probably do much better with just a K/V store. As for which is better - it's no contest. KyotoCabinet leaks pages like a sieve. http://www.anchor.com.au/blog/2013/05/second-strike-with-lightning/ Test LMDB in your own applications, you'll probably find that it massively outperforms whatever you were using before, as many others have. https://github.com/tspurway/pymdb-lightning Then there's the cost of conversion and added code size, for which Sqlite4 may be a winner, considered we'd need less changes and we'd likely have more code reuse from Sqlite3. Then there's memshrink, I couldn't find the maximum and average used memory in the reported benchmarks, we are currently using a max of 2MB per DB connection, would it be comparable? I finally wonder how they solved the problem of mmap corruption, also Sqlite can use mmap IO, and it may be up to ten times faster, but has no protection for memory corruption due to stray pointers or buffer overflows in the application. LMDB is protected from all of these problems. It uses a read-only memory map, so stray pointer writes will kill the app with SEGV, nothing corrupts the data on disk. So, it's definitely an option to consider when we decide to start working on a new generic storage, but we need far more details to be able to properly evaluate. Fwiw, Sqlite4 will support swappable engines, so you can use lmdb as the Sqlite4 engine, and a backend is already under development from what I read on the lmdb page. Yes, but SQLite4 is very very far away from ready for public consumption. The storage engine interface is pretty simple, plugging LMDB in is trivial. But until the frontend work is done (query optimizers and all that) it's not going to do anyone any good. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
unreported JS exception bugs
Seeing the filing of bug 895340 pushed me over the edge, because I knew we had many other similar bugs on file about unreported JS exceptions. I ended up filing https://bugzilla.mozilla.org/show_bug.cgi?id=895548, a tracking bug from which I could link a bunch of other related bugs that I found. I think many of them are probably related to the same underlying issues, and it would be great if someone more familiar with those issues and related code (bholley, mrbkap, bz?) could help clean up that bug list. It would also be useful if people who know of similar issues linked them to that tracking bug. These bugs often make debugging chrome JS a real pain. I realize they aren't all necessarily easy to fix, but I bet a bit of effort could go a long way to improving the lives of front-end developers and add-on authors. Gavin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using C++0x auto
On Fri, Jul 19, 2013 at 3:34 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: On 2013-07-18 5:48 AM, mscl...@googlemail.com wrote: r-value references 4.3@10.0! Yes This is very useful. I believe the JS engine already rolls their own tricks to implement this semantics. With this we can get rid of already_AddRefed and just pass nsRefPtr/nsCOMPtr/RefPtr around, right? Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: unreported JS exception bugs
On 7/18/2013 7:11 PM, Gavin Sharp wrote: Seeing the filing of bug 895340 pushed me over the edge, because I knew we had many other similar bugs on file about unreported JS exceptions. I ended up filing https://bugzilla.mozilla.org/show_bug.cgi?id=895548, a tracking bug from which I could link a bunch of other related bugs that I found. I think many of them are probably related to the same underlying issues, and it would be great if someone more familiar with those issues and related code (bholley, mrbkap, bz?) could help clean up that bug list. This is all related to a bug from relatively long ago, bug 393627. In this bug, people were complaining that in the following case, reporting an error is wrong: C++ (main) - JS code A - C++ B - JS code C throws exception If the C++ code B just sees the exception nsresult and immediately rethrows to JS code A, then we don't want to report that because the JS code might catch it. The result of this is that if there is *any* JS code on the stack, we don't report errors from deeper JS code. This is always the case in XPCShell. See in particular the logic around http://hg.mozilla.org/mozilla-central/annotate/af4e3ce8c487/js/xpconnect/src/XPCWrappedJSClass.cpp#l1001 I argued against fixing bug 415498 at the time, and because it was so contentious, there is an out: if you set MOZ_REPORT_ALL_JS_EXCEPTIONS you will get the old behavior (and the possibility of some false-positives). You can also call nsIXPConnect.setReportAllJSExceptions to set this at runtime. Other sordid history in this tale includes bug 415498, where the original code was found to be buggy and was eating error reports thrown from event listeners. My opinion is still that we should rip out most or all of this mechanism, and replace it with an opt-in mechanism for methods that actually do exception passthrough. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using C++0x auto
On Thu, Jul 18, 2013 at 11:34:53AM -0400, Ehsan Akhgari wrote: On 2013-07-18 5:48 AM, mscl...@googlemail.com wrote: From that table, using the gcc and msvc versions, that gives: gcc msvcclang auto 4.4 10.0* Yes Yes, please! decltype4.3@10.0@ 2.9 Yes, please! extern template 3.3 6.0Yes It's not exactly clear to me what the implications of using extern templates are. They promise faster build times. Has anybody tried to use them? More than faster build times, they also promise smaller objdir. The downside is that extern template class FooBar; may require Bar to be defined. Which potentially means adding #includes. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using C++0x auto
On 7/18/2013 7:15 PM, Robert O'Callahan wrote: On Fri, Jul 19, 2013 at 3:34 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: On 2013-07-18 5:48 AM, mscl...@googlemail.com wrote: r-value references 4.3@10.0! Yes This is very useful. I believe the JS engine already rolls their own tricks to implement this semantics. With this we can get rid of already_AddRefed and just pass nsRefPtr/nsCOMPtr/RefPtr around, right? I believe so. We can also add a non-broken variant of nsAutoPtr modeled after std::unique_ptr (allows moves but not copies). -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using C++0x auto
On Thu, Jul 18, 2013 at 08:54:02PM -0500, Joshua Cranmer ? wrote: On 7/18/2013 7:15 PM, Robert O'Callahan wrote: On Fri, Jul 19, 2013 at 3:34 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: On 2013-07-18 5:48 AM, mscl...@googlemail.com wrote: r-value references 4.3@10.0! Yes This is very useful. I believe the JS engine already rolls their own tricks to implement this semantics. With this we can get rid of already_AddRefed and just pass nsRefPtr/nsCOMPtr/RefPtr around, right? I believe so. We can also add a non-broken variant of nsAutoPtr modeled after std::unique_ptr (allows moves but not copies). Note that STL is another story. We're not using libstdc++ that comes with the compiler on android and b2g. We use STLport instead, and STLport has, afaik, no support for C++11 STL types. So, while we can now fix nsAutoPtr to use move semantics instead of copy semantics, we can't use std::unique_ptr. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: unreported JS exception bugs
On 7/18/13 9:27 PM, Benjamin Smedberg wrote: My opinion is still that we should rip out most or all of this mechanism, and replace it with an opt-in mechanism for methods that actually do exception passthrough. For what it's worth, that's how the mechanism for calling JS from C++ via WebIDL bindings works: Exceptions in JS are reported unless the C++ caller explicitly opts in to rethrowing them. And in that case we assert if it doesn't check whether it needs to rethrow, even if there is no exception thrown, so the exceptions won't disappear due to inattentiveness. The xpidl story is a bit more complicated because it tries to make it transparent whether you're calling C++ or JS, so you can't just put the opt-in in the function signature like we do for WebIDL. But maybe we could just set up a simple RAII class for doing such opt-in... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: unreported JS exception bugs
On Thu, Jul 18, 2013 at 4:11 PM, Gavin Sharp ga...@gavinsharp.com wrote: Seeing the filing of bug 895340 pushed me over the edge, because I knew we had many other similar bugs on file about unreported JS exceptions. I ended up filing https://bugzilla.mozilla.org/show_bug.cgi?id=895548, a tracking bug from which I could link a bunch of other related bugs that I found. I think many of them are probably related to the same underlying issues, and it would be great if someone more familiar with those issues and related code (bholley, mrbkap, bz?) could help clean up that bug list. The current exception handling mechanism in XPConnect is, in my assessment, broken and fragile beyond repair. I'm incrementally simplifying a lot of related machinery (with the end goal of removing JSContexts altogether), after which point it will be much simpler to put together a sane and predictable exception mechanism. We have plans for this, in another off-list thread. That is to say, I'm working on the big picture, and not particularly inclined to work on specific cases of the current general brokenness in the mean time. bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: requiring build peer review for Makefile.in changes
On 18/07/13 12:00, Gregory Szorc wrote: Since new Makefile.in badness makes people's lives harder (especially when it makes the build slower), I would like to propose a more strict policy around Makefile.in changes: *if a non-list change in a Makefile.in isn't reviewed by a build peer, it doesn't land or gets backed out.* This could potentially be enforced with repository push hooks. It is about time we added something like: $ mach commit-check tip In this case checking the r= in the commit comment would work. It could easily be extended to pick up other obvious mistakes like adding lines with white space at the end. We could run it before doing a bzexport. Anthony ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
