Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
Hi Everyone, Taking in all of the feedback received, Byron came up with updated proposal in https://bugzilla.mozilla.org/show_bug.cgi?id=851818#c3 that I think will address the needs of the feedback provided here. If you have any additional comments, feedback, etc, please feel free to provide that information by replying to this thread. Sincerely, Jason Smith ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: ManifestDestiny
On Tuesday, March 19, 2013 5:37:22 AM UTC-4, Robert O'Callahan wrote: Cool name. However, are you actually proposing replacing, say, the reftest manifest format with this format? It looks like it would be a lot more verbose. My understanding is there is no need or plan to replace the reftest manifest format with ManifestDestiny. Right now this is used for xpcshell, and we are working towards making it work for mochitests. Trying to make a one size fits all solution doesn't really make sense for all of the different harnesses. The reftest .list format is too clunky for just listing out tests to run, likewise the ManifestDestiny .ini format is too awkward to list A vs B type of comparisons along with complex conditions. -Joel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
On Mon, 18 Mar 2013 20:52:23 +0100, Anthony Ricaud wrote: On 18/03/13 17:39, L. David Baron wrote: On Monday 2013-03-18 09:27 -0700, Jason Smith wrote: I'd actually like to see Core higher on the list for the no-canconfirm case. I think it's common for reasonably well-informed Web developers (who would have been able to choose a reasonably correct component within Core, given the list) to file standards bugs and end up with them languishing in Firefox::General. And I think appropriate guiding for Web developers filing bugs against the rendering engine is an important case. I'd suggest renaming Core here. Web developers don't understand what Core is. They might know Gecko though. Does it make sense to rename Core to Gecko? I'm sure web developers have heard of Gecko (Webkit, Trident, etc) but do they know what Gecko actually covers? Changing Core to Gecko just changes one funny code word with another funny code word. Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MemShrink meeting: Today March 19, 2013 @ 4:00pm PDT
Note new meeting time: Tuesday, 19 March 2013, 16:00:00 Today's MemShrink meeting will be brought to you by this fixed bug: https://bugzilla.mozilla.org/show_bug.cgi?id=843733 The wiki page for this meeting is at: https://wiki.mozilla.org/Performance/MemShrink Agenda: * Discuss Images Memory Usage * Prioritize unprioritized MemShrink bugs. * Discuss how we measure progress. * Discuss approaches to getting more data. Meeting details: * Tue, March 19, 2013, 4:00 PM PDT * PBJ, Mountain View office, 3rd floor. * Dial-in Info: - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference num 95346 --Jet ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
I disagree on Calendar being on that list. Doing some Bugzilla diving shows that the number of bugs filed in Calendar over the past month was around ~30 or so bugs. That's less than the Gaia Calendar app itself (which is a Bugzilla component) and is on the low end in comparison to other Bugzilla products. I don't think there's any data to justify the Calendar component remaining on the enter bug page if the bug filing rate is too low. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
jsmith.mozi...@gmail.com wrote: I disagree on Calendar being on that list. Doing some Bugzilla diving shows that the number of bugs filed in Calendar over the past month was around ~30 or so bugs. That's less than the Gaia Calendar app itself (which is a Bugzilla component) Are these bugs filed by users with and/or without canconfirm and/or canedit? -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Decoupling the build config via moz.build files (nuking all.js)
On 03/19/2013 07:33 AM, Joshua Cranmer wrote: On 3/18/2013 11:27 PM, Jeff Hammel wrote: On 03/15/2013 11:33 AM, Gregory Szorc wrote: Our build config has a number of areas where metadata is centrally defined and a module or component's configuration is fragmented in the source tree. Here are some examples: snip/ 3) xpcshell.ini master manifest. /testing/xpcshell/xpcshell.ini defines every xpcshell.ini that exists in the tree. http://mxr.mozilla.org/mozilla-central/source/testing/xpcshell/xpcshell.ini Not sure if this is meant in terms of how the submanifests or laid out or precisely what the issue is here or what is desired; this isn't really addressed in the rest of the email (ABICT). Our plan is to get more testing frameworks on manifests. See https://bugzilla.mozilla.org/show_bug.cgi?id=852418 . This allows fine-grained control of what is run on what platform (and whatever other conditionals are encountered), notation for the reason tests are disabled, and whatever other notations are desired. In addition, we are gearing towards the ability to use and manipulate manifests via tools and automation, such as on-the-fly generation of manifests and information harvesting from manifests convolved with other sources. While xpcshell currently has one top-level manifest (I think?), there is no reason we couldn't have more. The current master manifest approach is, in my opinion, horribly broken: there is no way to conditionally include/exclude directories based on criteria other than what is included in mozinfo.json--which notably excludes things like am I building Firefox or Thunderbird? File a bug. Seriously, if the lack of this metadata == horribly broken then I am really glad that horribly broken is easy to fix. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Decoupling the build config via moz.build files (nuking all.js)
On 03/18/2013 09:45 PM, Gregory Szorc wrote: On 3/18/2013 9:27 PM, Jeff Hammel wrote: On 03/15/2013 11:33 AM, Gregory Szorc wrote: Our build config has a number of areas where metadata is centrally defined and a module or component's configuration is fragmented in the source tree. Here are some examples: snip/ 3) xpcshell.ini master manifest. /testing/xpcshell/xpcshell.ini defines every xpcshell.ini that exists in the tree. http://mxr.mozilla.org/mozilla-central/source/testing/xpcshell/xpcshell.ini Not sure if this is meant in terms of how the submanifests or laid out or precisely what the issue is here or what is desired; this isn't really addressed in the rest of the email (ABICT). Our plan is to get more testing frameworks on manifests. See https://bugzilla.mozilla.org/show_bug.cgi?id=852418 . This allows fine-grained control of what is run on what platform (and whatever other conditionals are encountered), notation for the reason tests are disabled, and whatever other notations are desired. In addition, we are gearing towards the ability to use and manipulate manifests via tools and automation, such as on-the-fly generation of manifests and information harvesting from manifests convolved with other sources. While xpcshell currently has one top-level manifest (I think?), there is no reason we couldn't have more. Nah, I'm not against manifests. I think they make a lot of sense for things like tests. We /almost/ used them as the moz.build equivalent! I'm just opposed to centralized, monolithic lists/manifests of things when the data is actually spread out across the tree. Individual xpcshell.ini (like /services/sync/tests/unit/xpcshell.ini) are fine. What I don't like is /testing/xpcshell/xpcshell.ini. The latter simply references a bunch of the former because we don't have an easy way to aggregate all occurrences of the former in a Makefile-based build system aside from directory scanning or other funkiness. moz.build files allow us to easily capture a whole-world view. So, we can do things like dynamically generate master manifests for the current build, etc. Make sense? Maybe? ;) I'd have to see a bug etc for more of an opinion. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Running Windows 8 tests visibly on mozilla-central, mozilla-inbound and try
Hi, Besides three test suites (reftests, debug m-2 and debug m-o) all other jobs are running constantly green. If you want to read more about it visit http://armenzg.blogspot.ca/2013/03/running-windows-8-tests-visibly-on-tbpl.html best regards, Armen ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Decoupling the build config via moz.build files (nuking all.js)
On 3/19/13 11:57 AM, jmaher wrote: The consensus is the master manifest solution is not of interest, are there proposals and plans to remove: testing/xpcshell/xpcshell.ini testing/crashtest/crashtests.list layout/reftest/reftests.list This thread seems as though it is focusing on one of the 3 master manifests. As I am working towards adding a manifest solution for mochitests, I would really like to know what is an agreed upon forward solution here. We just had a long conversation in #automation and I the outcome was something along the lines of: * Master manifests checked into the tree are silly for reasons outlined in this thread. * moz.build files will at most be the manifests or at least link to each manifest file. * Master manifests can be derived by smaller, individual manifests at build config time (output of moz.build traversal). There is an open question of whether to use moz.build files to declare test files, etc or whether to use something else. If something else, we could use one of the existing manifest formats or use a moz.build Python sandbox variation. I personally don't care too much. The important property from a build config perspective is that the build config can read data out of the manifests and use it as part of building the tree. If moz.build files don't contain the data themselves, then we need a Python API to parse the manifests at build config time. If the build config can see all, it can easily write out a master manifest, a JSON file, or something else that can be read by the test runners. If I had to weigh in, I think existing manifests like xpcshell.ini work good enough and might be more readable and maintainable than managing everything in moz.build files. But, I'm ignorant of a lot of things, so maybe they aren't good enough. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running Windows 8 tests visibly on mozilla-central, mozilla-inbound and try
On Tuesday 2013-03-19 14:34 -0400, Armen Zambrano G. wrote: Subject: Running Windows 8 tests visibly on mozilla-central, mozilla-inbound and try Besides three test suites (reftests, debug m-2 and debug m-o) all other jobs are running constantly green. If you want to read more about it visit http://armenzg.blogspot.ca/2013/03/running-windows-8-tests-visibly-on-tbpl.html What about all the other branches that merge into mozilla-central? Isn't it essentially a rule that tests shouldn't be enabled on mozilla-central without also enabling them on the branches that merge into mozilla-central? Otherwise, test failures end up being introduced in branch merges without a decent way of diagnosing or (since it's hard to back out a merge) a decent way of backing out. Also, shouldn't this be posted to dev-tree-management? And perhaps also dev-planning rather than dev-platform? -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
