Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
Seems like a good proposal, but dev-platform doesn't really feel like the best place to get feedback from the people affected. Not sure what would be, though. (on Labs: There's a bunch of smaller projects there, but I don't mind if they're slightly harder to find) --da On Mon, Mar 18, 2013 at 9:27 AM, Jason Smith jsm...@mozilla.com wrote: Hi Everyone, In bug 851818 (https://bugzilla.mozilla.org/**show_bug.cgi?id=851818https://bugzilla.mozilla.org/show_bug.cgi?id=851818), I've filed a bug to suggest rethinking what our enter bug entry page for users who are filing bugs with canconfirm or no canconfirm access. I'd like to discuss what changes we should make to that enter bug entry page such as adding new products to the list that we think should be there, keeping certain products on the list that are important enough to remain there, and removing certain products that we don't think need to be there. I've outlined the state of enter bug entry pages under canconfirm and no canconfirm below and included my initial thoughts below. Thoughts? *existing canconfirm access* *enter bug entry page list* - Core - Firefox - Thunderbird - Calendar - Camino - SeaMonkey - Firefox for Android - Mozilla Localizations - Mozilla Labs - Mozilla Services - Other Products *existing no canconfirm access enter bug entry page list* - Firefox - Firefox for Android - Thunderbird - Mozilla Services - SeaMonkey - Mozilla Localizations - Mozilla Labs - Calendar - Core *Ideas for what products we should add* - BootToGecko (canconfirm and not canconfirm) - Firefox for Metro (canconfirm and not canconfirm) - Marketplace (canconfirm and not canconfirm) *Ideas for what products we should remove* - Thunderbird (canconfirm and not canconfirm) - Calendar (canconfirm and not canconfirm) - Camino (canconfirm and not canconfirm) - SeaMonkey (canconfirm and not canconfirm) - Mozilla Labs (canconfirm and not canconfirm) *Rationale for Additions* - BootToGecko - Big focus at Mozilla with a lot of people working on this project, so I think this could benefit greatly from being on the front page. - Firefox for Metro - Important for our Windows 8 story and could probably benefit for contributors from knowing up front where to file bugs on this while it's under development - Marketplace - Important in conjunction with BootToGecko and a common bugzilla product I don't think people realize exists. In doing bug triage for B2G, there's very high cases where bugs for Marketplace have ended up in the incorrect component, so I'm hoping putting this on the front page will increase likelihood that the bug ends up in the right spot. *Rationale for Removals* - Thunderbird - Decreased focus at Mozilla now that has moved to contribution only now, so I don't think this needs to be on the front page. - Calendar - Decreased focus at Mozilla overall in comparison to other products on the front page - Camino - Low focus at Mozilla overall in comparison to other products on the front page - SeaMonkey - Low focus at Mozilla overall in comparison to other products on the front page - Mozilla Labs - Looks like an outdated Bugzilla product that may not have high bug filing usage - probably does not need to be on the front page -- Sincerely, Jason Smith Desktop QA Engineer Mozilla Corporation https://quality.mozilla.com __**_ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/**listinfo/dev-platformhttps://lists.mozilla.org/listinfo/dev-platform ___ 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 Monday 2013-03-18 09:27 -0700, Jason Smith wrote: *existing canconfirm access* *enter bug entry page list* - Core - Firefox - Thunderbird - Calendar - Camino - SeaMonkey - Firefox for Android - Mozilla Localizations - Mozilla Labs - Mozilla Services - Other Products *existing no canconfirm access enter bug entry page list* - Firefox - Firefox for Android - Thunderbird - Mozilla Services - SeaMonkey - Mozilla Localizations - Mozilla Labs - Calendar - Core 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. -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
Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
On 18/03/2013 16:27, Jason Smith wrote: - BootToGecko - Big focus at Mozilla with a lot of people working on this project, so I think this could benefit greatly from being on the front page. This should be Firefox OS as that's what the users will know it as. *Rationale for Removals* - Thunderbird - Decreased focus at Mozilla now that has moved to contribution only now, so I don't think this needs to be on the front page. Mozilla is still committed to providing security and stability updates, as well as enabling those contributions. We need the bug reports to enable this to happen, and I think making Thunderbird harder to find would send the wrong message here. Mark. ___ 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 have a concern that removing active community projects would increase the community/MOCO divide. Kevin On Mar 18, 2013 10:35 AM, Mark Banner mban...@mozilla.com wrote: On 18/03/2013 16:27, Jason Smith wrote: - BootToGecko - Big focus at Mozilla with a lot of people working on this project, so I think this could benefit greatly from being on the front page. This should be Firefox OS as that's what the users will know it as. *Rationale for Removals* - Thunderbird - Decreased focus at Mozilla now that has moved to contribution only now, so I don't think this needs to be on the front page. Mozilla is still committed to providing security and stability updates, as well as enabling those contributions. We need the bug reports to enable this to happen, and I think making Thunderbird harder to find would send the wrong message here. Mark. __**_ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/**listinfo/dev-platformhttps://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Changed behavior: writing to console.log file
Hi all, Since https://bugzilla.mozilla.org/show_bug.cgi?id=833939 recently landed on central, I'd like to inform you all of its implications: * Debug builds no longer write the logs to a file called `console.log` in the users' AppData directory (for example `~/Library/Application Support/Firefox/console.log` on OSX. These files were reported to grow very large unnoticed (400MB+) and this change will prevent that from happening in the future. * Old log files are not removed by this patch. Please perform the necessary cleanup yourself by removing the `console.log` file from the AppData directory. * If you depend on this feature to work - to analyze issues during program startup, for example - you can set the `XRE_CONSOLE_LOG` environment variable to a valid path on your system or use the NS_ENSURE_SUCCESS_LOG / NS_ENSURE_TRUE_LOG macros from C++ directly. For more information, please read the bug mentioned above or ping me on IRC: mikedeboer. Mike. ___ 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 2013-03-18 12:39 PM, L. David Baron 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 agree with all of this, but I think that even very well-informed Web developers might find the Core component list daunting and incomprehensible. I think it'd be a good idea to have a special bug-entry wizard just for Firefox didn't render this page correctly that knows how to map standard web development terminology (HTML, JavaScript, CSS, tables, forms, accessibility, ...) to components, and which also encourages inclusion of things like self-contained minimal test cases, screen shots, and cross-browser comparisons. zw ___ 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
Jason Smith schrieb: *Ideas for what products we should remove* And how the XXX should users of those products file new bugs then? Robert Kaiser ___ 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
Sounds good to me. Also to add in a piece of private feedback I received - SeaMonkey wants to remain on the front page as there's a strong community behind it that still works on that project. Sincerely, Jason Smith Desktop QA Engineer Mozilla Corporation https://quality.mozilla.com On 3/18/2013 9:39 AM, L. David Baron wrote: On Monday 2013-03-18 09:27 -0700, Jason Smith wrote: *existing canconfirm access* *enter bug entry page list* - Core - Firefox - Thunderbird - Calendar - Camino - SeaMonkey - Firefox for Android - Mozilla Localizations - Mozilla Labs - Mozilla Services - Other Products *existing no canconfirm access enter bug entry page list* - Firefox - Firefox for Android - Thunderbird - Mozilla Services - SeaMonkey - Mozilla Localizations - Mozilla Labs - Calendar - Core 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. -David ___ 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 3/18/13 10:14 PM, Jason Smith wrote: Sounds good to me. Also to add in a piece of private feedback I received - SeaMonkey wants to remain on the front page as there's a strong community behind it that still works on that project. For similar reasons I would like Calendar to stay on the main page. Despite it being a community project, it is still active. Users already have enough trouble with update woes and whatnot, removing Calendar from the front page would make it even harder to file Calendar bugs. I have similar feelings for any active project. Philipp ___ 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
(2013/03/19 2:31), Mark Banner wrote: On 18/03/2013 16:27, Jason Smith wrote: - BootToGecko - Big focus at Mozilla with a lot of people working on this project, so I think this could benefit greatly from being on the front page. This should be Firefox OS as that's what the users will know it as. I feel new entries are justified. *Rationale for Removals* - Thunderbird - Decreased focus at Mozilla now that has moved to contribution only now, so I don't think this needs to be on the front page. Mozilla is still committed to providing security and stability updates, as well as enabling those contributions. We need the bug reports to enable this to happen, and I think making Thunderbird harder to find would send the wrong message here. Removing ThunderBird will give wrong signals. I am afraid that will reduce the user base even though ESR seems to be well received today. At the next release cycle, we will see large departure and thus this removal negates the idea of community-support. We will enter cycles of reduced number of users, reduced number of feedbacks, and thus eventual demise sooner than otherwise. IMHO. That removal will start me pondering what to do with my mailer (currently TB), too. Mark. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ 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
Robert Kaiser wrote: *Ideas for what products we should remove* And how the XXX should users of those products file new bugs then? we're talking about removing products from the list of products initially shown to users, not about removing the products from bmo completely. the complete list of products will always be a single click away. Philipp Kewisch wrote: I have similar feelings for any active project. there are *many* active projects/products which are not initially shown; i don't think that alone is good enough criteria for inclusion in the list. finding the product isn't difficult, via clicking on other products or searching with the search field. if someone isn't able to find the calendar product via either of these, i would question the value of their bug report :) L. David Baron 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. if you select 'firefox' from the guided bug form, your bug is forced into the 'firefox::untriaged' component. if their bugs are landing in firefox::general, it would be because either they are switching to the advanced form and selecting that product/component, or triage are incorrectly moving bugs from firefox::untriaged to firefox::general instead of into the core product. in either case, moving core up in the list won't address this issue. on the guided bug form there's always been a link report an issue with firefox on a site that i've developed, which takes you to the core product. instead of moving core, i'd rather draw more attention to this link. -- byron - irc:glob - bugzilla.mozilla.org team - ___ 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)
1) Preferences and all.js. We currently define most of the default preferences in /modules/libpref/src/init/all.js. There are things in there related to the browser, Necko, gfx, dom, etc. Prety much the kitchen sink. 2) Telemetry histograms. They are all defined in /toolkit/components/telemetry/Histograms.json. Same deal as all.js: bits from multiple modules all exist here. If the proposal is that each module could have its own prefs and histograms files, I am not convinced this would be an improvement over the current situation. At the very least, we should consider the downsides to splitting these files up. The putative advantages to splitting these files up are * including increased utility of |hg log| * easier code comprehension (since everything is self-contained). * faster builds (from splitting up Histograms.json, bug 831104). I don't think splitting up the files would result in a big improvement in any of these areas. To address each in turn: * including increased utility of |hg log| Splitting up the files would also decrease the utility of hg/git log. Right now it's easy to say show me all pref changes in all.js. But if we split all.js up into many separate files, I'd have to do |git log foo/bar/prefs.js foo/baz/prefs.js ...| Module boundaries are always blurry, so show me all image pref changes wouldn't necessarily be as simple as |git log image/prefs.js|. For example, the pref for image locking is content.image.allow_locking. I think this is an image pref, but obviously whoever wrote it thought it was a content pref. * easier code comprehension (since everything is self-contained). I don't think this is a big advantage. Modules are so large, the only way to navigate around one is by searching. Does the fact that I have to use my editor's find command to navigate all.js really stand in the way of comprehension? Again splitting the files also makes code comprehension more difficult in some circumstances. Currently, if I want to find out a pref's value in b2g, I have search through two files. Under the proposed scheme, I'd have to search through N files. This is a net loss in my ability to comprehend the code. * faster builds (from splitting up Histograms.json, bug 831104). We could accomplish these build speedups by putting the split-up probe-definition files all in one directory (instead of spreading them around the tree). That would be fine with me, if the build speedups here are something that we really want. In practice, we have lots of headers that are included all over the tree. Some of them (e.g. nsContentUtils.h) are modified quite often. I'd rather focus on making rebuild-the-world builds faster (e.g. with PCH) than try to fix each of these cases piecemeal. In addition to not having large benefits, splitting up prefs and telemetry would have considerable costs. The two big ones which come to mind are: * Increased difficulty figuring out what's the default value of pref X on product Y? because given a pref name it's not clear where it lives in the tree. (Establishing a simple function mapping pref names to tree locations would require mass-modifying a lot of pref names, which would break users who have those prefs set to custom values, so I don't think we can do that.) * What happens when two files define the same pref? In order to be sane, we'd have to make that a build error. But then because some modules can be disabled conditionally, some pref files will be disabled conditionally. This introduces a whole new combinatorial way to break the build with weird configurations. -Justin On Sat, Mar 16, 2013 at 3:33 AM, Gregory Szorc g...@mozilla.com 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: 1) Preferences and all.js. We currently define most of the default preferences in /modules/libpref/src/init/all.js. There are things in there related to the browser, Necko, gfx, dom, etc. Prety much the kitchen sink. 2) Telemetry histograms. They are all defined in /toolkit/components/telemetry/Histograms.json. Same deal as all.js: bits from multiple modules all exist here. 3) xpcshell.ini master manifest. /testing/xpcshell/xpcshell.ini defines every xpcshell.ini that exists in the tree. I think all of these (and more) are sub-optimal because it creates a strong and possibly unwanted coupling between modules while fragmenting a module/component's code. In my ideal world, I'd like to see as much of the code as possible for a module/component be self-contained and loosely coupled from the rest of the tree. There are a number of reasons for this, including increased utility of |hg log| and easier code comprehension (since everything is self-contained). The latter likely results in less tree cruft over time. In case of Telemetry histograms, decoupling can even make the tree build
