Re: Intent To Require Manifests For Vendored Code In mozilla-central
Mark Banner wrote: There are some directories where we only import a file from a third-party and it is alongside other files in that same directory, e.g. testing/modules has "ajv-4.1.1.js" and "sinon-2.3.2.js" imported from elsewhere. How do they fit into this scheme? they would have to be moved into their own directories. One thing we do need is a way for the build system to give us a list of files and directories that are from third-parties, imported, etc. Can that be provided as a result of this work? yes; that list would be useful to multiple consumers. scoping vendoring to a directory level makes generation of that list easier and quicker. -- glob — engineering workflow — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent To Require Manifests For Vendored Code In mozilla-central
Axel Hecht wrote: One thing I'm missing is the ability to do mono-repo imports. Say we want to vendor in https://github.com/projectfluent/fluent.js/tree/master/fluent-gecko. i'm not sure i understand the specific concerns around mono-repos; you can use exclude/include to perform a selective import. since fluent.js is a node project i suspect the best option right now is to manually vendor the externally built jsm artefacts, with a minimal moz.yaml documenting the source. once we support node in-tree we can revisit how best to deal with automatic vendoring of the source. For js libraries, we might also want to pay attention to .npmignore (others already mentioned hg, so also .hgignore). i'm not sure how this is relevant. why would there be files in the source repo that have been excluded from source control? There's no spec what happens with patches that fail to apply, or failed run_after scripts. vendoring would require all steps to be successful. Do we intend to do something if the LICENSE changes? Also, what are we supposed to do if the vendored code doesn't have a LICENSE file? currently you can't just vendor anything into mozilla-central; there's a list of compatible licenses. moz.yaml will make it possible to audit and later enforce that vendored code honours our licensing requirements. this already happens for rust crates. licens...@mozilla.org is the point of contact for these sorts of issues. -- glob — engineering workflow — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent To Require Manifests For Vendored Code In mozilla-central
this should be: https://goo.gl/QZyz4x for the full specification. This format is essentially assuming the vendored code comes from a VCS repository. We have plenty of third party code that is imported through upstream tarballs, so this should probably be accounted for. we can certainly support tarballs at a later stage. i've expanded the comment for the url field to indicate it can point any location, with the limitations applying to automated vendoring. How does this fit with rust vendoring? Most if not all the information from your proposed moz.yaml is available in Cargo.toml. Do we need to duplicate this? Does mach vendor rust need to create moz.yaml files from Cargo.toml when it does the vendoring? i don't think there's a need to duplicate the information that's in Cargo.toml. if this pans out to be problematic moz.yaml generation during rust vendoring sounds viable. -- glob — engineering workflow — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent To Require Manifests For Vendored Code In mozilla-central
this should be: https://goo.gl/QZyz4x for the full specification. This format is essentially assuming the vendored code comes from a VCS repository. We have plenty of third party code that is imported through upstream tarballs, so this should probably be accounted for. we can certainly support tarballs at a later stage. i've expanded the comment for the url field to indicate it can point any location, with the limitations applying to automated vendoring. How does this fit with rust vendoring? Most if not all the information from your proposed moz.yaml is available in Cargo.toml. Do we need to duplicate this? Does mach vendor rust need to create moz.yaml files from Cargo.toml when it does the vendoring? i don't think there's a need to duplicate the information that's in Cargo.toml. if this pans out to be problematic moz.yaml generation during rust vendoring sounds viable. -- glob — engineering workflow — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent To Require Manifests For Vendored Code In mozilla-central
glob wrote: The plan is to create a YAML file for each library containing metadata such as the homepage url, vendored version, bugzilla component, etc. See https://goo.gl/QZyz4xfor the full specification. this should be: https://goo.gl/QZyz4x for the full specification. -- glob — engineering workflow — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Phabricator/Lando update, November 2017
TOTP does not require a smartphone. there's software TOTP clients that can be run on your desktop, and i'm also seeing TOTP support baked into some password managers. that clearly isn't as secure as the second factor implemented on a second device, however desktop TOTP does provide better security than password-only authentication. if you care about security and shun smartphones there are also plenty of "one time password token" hardware devices that perform the same function. i have a yubikey for my 2fa needs, mostly because it's more convenient than reaching for my phone. -glob Masatoshi Kimura wrote: I went to the 2FA preference on BMO. For me, the only authentication option was TOTP that requires a smartphone. I do not have a smartphone like Mark. How can I continue to contribute after we are forced to use Phabricator? Mozilla no longer wants volunteer contributors? On 2017/11/30 3:05, Mark Côté wrote: Right, I should have mentioned that. We are working right now on enforcing MFA for Phabricator via BMO. See https://bugzilla.mozilla.org/show_bug.cgi?id=1393950. Should go out next week. Mark On Nov 29, 2017 12:41 PM, "Andreas Tolfsen" wrote: Also sprach Mark Côté: We were hesitant to advertise this too widely in order not to create any confusion around the Quantum release, but now that that has settled down I am told it should be fine for anyone to start using it. The instance is at https://phabricator.services.mozilla.com/ and there are docs at https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html. I’ve been wanting to try out the new review tool, but the sign up steps in the documentation fails to mention two-factor authentication. The only option is ‘Mobile Phone App (TOTP)’ and if you, like me, don’t have a smartphone it is seemingly impossible to create an account. I would’ve thought it would delegate the MFA bit to Bugzilla, or am I doing something wrong? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- glob — engineering productivity — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [PATCH] gfx: thebes: decouple GfxSurfaceType from cairo_surface_type_t
yes - https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/How_to_Submit_a_Patch covers this. please read all of the document linked by cameron and this one. -glob Enrico Weigelt, metux IT consult wrote: On 31.07.2017 09:23, Cameron McCormack wrote: Hi Enrico, Firefox patches should be submitted via Bugzilla, rather than by email to dev-platform. Please see: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction#Step_4_-_Get_your_code_reviewed Is there a way to submit via mail ? Or some git-send-email counterpart ? Always going through the web frontend manually would be pretty time consuming ... --mtx -- glob — engineering productivity — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Phabricator Update, July 2017
Milan Sreckovic wrote: One thing that hasn't been explicitly mentioned, and I hope switching to phabricator would fix it (though it does sounds like an orthogonal issue) - the patches that are attached to bugzilla are often not the ones that actually landed, because last minute changes were made and landed manually. Will that get better with phabricator? the switch to phabricator won't directly address that issue. requiring autoland will. this is a topic that came up on this list when requiring landing through autoland was proposed - https://groups.google.com/d/msg/mozilla.dev.platform/hp5_6OAKV_c/JNWydrDVBAAJ it's a policy decision that hasn't been completely decided. how our team currently works when using mozreview is if there's an r+ with "fix on commit" changes required, we'd make those changes, push up the revised version to mozreview, carry forward the r+, and use autoland to land. -- glob — engineering productivity — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Phabricator Update, July 2017
Consider that we are talking about "turning off" mozreview now. Will all the bugzilla links to those reviews go dead? Or do we have to maintain a second service in read-only mode forever? the patches will be archived in some form. how this looks is yet to be fully fleshed out - ideas currently include archiving and updating bugzilla to point to their new location (eg. s3), or uploading patches directly to bugzilla. -- glob — engineering productivity — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Phabricator Update, July 2017
Yeah, I live in the assumption that bugzilla bugs will contain all the review information also in phabricator era. i believe the current plan is to mirror just the outcome of the review to bugzilla (ie. that a review exists, and set the review flag). if comments should be mirrored to bugzilla has been a topic of much discussion, so this may change. i'm of the opinion that *not* mirroring comments to bugzilla is the right thing to do. phabricator provides a better experience for tracking reviews and notifications (eg. you can watch files/directories and be notified when reviews are posted that touch that code). one of my largest concerns is duplicating comments into bugzilla splits review dialog between two systems making it harder to follow conversations (unless you do bidirectional sync, which has its own set of problems). But indeed having also the patches in bugzilla would be good. no, it would be bad for patches to be duplicated into bugzilla. we're moving from bugzilla/mozreview to phabricator for code review, duplicating phabricate reviews back into the old systems seems like a step backwards (and i'm not even sure what the value is of doing so). -- glob — engineering productivity — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Phabricator Update, July 2017
To answer the other part of your question, MozReview will be disabled for active use across the board, but it is currently used by a small number of projects. Splinter will be disabled on a per-product basis, as there may be some projects that can't, won't, or shouldn't be migrated to Phabricator. Splinter is still a nice UI to look at patches already attached to bugs. Please don't disable it. excellent point; thanks for that feedback. instead of disabling splinter for phabricator backed products, we could make it a read-only patch viewer. -- glob — engineering productivity — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of commit access policy for core Firefox
David Burns wrote: We should try mitigate the security problem and fix our nit problem instead of bashing that we can't handle re-reviews because of nits. one way tooling could help here is to allow the reviewer to make minor changes to the patch before it lands. ie. "r+, fix typo in comment before landing" would become "r+, i fixed the comment typo" -- glob — engineering productivity — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: ANN: Default bug view for BMO changed today!
Jörg Knobloch wrote: Some more feedback: While "3 years ago" is nice for the date display, I'd also like to see the full date and hour in a copyable form. Another bug for that? Or is there a setting that will do it already? set "Use absolute format instead of relative time when viewing a bug" https://bugzilla.mozilla.org/userprefs.cgi?tab=settings#ui_use_absolute_time -- glob — engineering productivity — moz://a ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: DXR problem?
Richard Z wrote: tried dxr as replacement for lxr yesterday and today and it does not seem to work for me. Whatever I type into the searchbox the results is just an empty "This page was generated by DXR ."? https://dxr.mozilla.org/mozilla-central/search?q=voice&redirect=true Displaying source like https://dxr.mozilla.org/mozilla-central/source/mobile/android/modules/Prompt.jsm works but does not provide any xref links?? this sounds like https://bugzilla.mozilla.org/show_bug.cgi?id=1283645 dxr uses "let" and "const", which aren't supported in all browsers, including older versions of firefox. -- glob — engineering productivity — mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Triage Plan for Firefox Components
Gervase Markham wrote: On 01/04/16 15:51, Mike Hommey wrote: Bug status is currently, IMHO, completely misused and thus useless: - people with editbug capability file as NEW by default. Why should a bug I file in a component I'm not working on (because I noticed a bug in Firefox) be NEW? - there is a long tail of bugs assigned to people that are not being worked on (I should know, I have a lot of those, shame on me) So it feels to me triage should replace/subsume it in some way. I suspect they want to add a new field because changing bug statuses seems like a massive change. Which it would be. However, not doing it will leave us with two workflow widgets in Bugzilla instead of one, with all the ambiguity that brings. In the long term, I see pain here. right - adjusting the workflow is a silently breaking one so we're not taking that step just (yet!). eg. dashboards that use a hardcoded list of "open" states will silently stop reporting on all bugs if we add a new state. If Bugzilla supported per-product workflow that might help. Is it worth investing the BMO-hacking resources for this plan into that? the plan is to have per-product customisations in the UI with per-product workflow enforcement via extensions. "per-product workflows" isn't an option as we're not altering the BMO workflow fields (status/resolution) in a way that would make this viable. imho long term the list of status/resolutions needs to be updated; but first we need to determine, document, and mandate the desired workflow. emma's work is the first step of this process, and i expect somewhere near the end lives a "break all the things" change for the greater good. -glob -- byron jones - :glob - bugzilla.mozilla.org team lead - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Merge moved to Thursday 29th
Sylvestre Ledru wrote: Because we want to synchronize the release of 42 and 44 devedition (next Tuesday), we are planning to perform the merge tomorrow, Thursday. As a consequence, nightly = 45, aurora = 44 and beta = 43 (42 is already in release). This will give us enough time to validate the first aurora build. I apologize for the very late notice. Of course, we will be friendly with uplift requests. please update https://wiki.mozilla.org/RapidRelease/Calendar and the associated ICS files. thanks. -- byron jones - :glob - bugzilla.mozilla.org team lead - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Voting in BMO
Byron Jones wrote: this feature exists and is called "bug tagging". you'll need to enable it via the prefs page (it's disabled by default because the ux needs some love). https://www.bugzilla.org/docs/4.2/en/html/query.html#individual-buglists (section 5.5.5). i should add that the plan for this is to make it much more discoverable. this will likely involve renaming it to "favourites" (or similar) to better reflect the personal nature of these lists, and a complete overhaul of its user interface. -glob -- byron jones - :glob - bugzilla.mozilla.org team lead - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Voting in BMO
Dale Harvey wrote: As a developer of a bugzilla client however I have see a major missing feature being the ability to favourite bugs in bugzilla., not to cc and get a baggage of email but somewhere you can keep check on a list of bugs you have an interest in, personally I make a meta bug and block it with bugs I am interested in (https://bugzilla.mozilla.org/show_bug.cgi?id=965185) but I could see "vote" being re purposed as favourite very easily this feature exists and is called "bug tagging". you'll need to enable it via the prefs page (it's disabled by default because the ux needs some love). https://www.bugzilla.org/docs/4.2/en/html/query.html#individual-buglists (section 5.5.5). -glob -- byron jones - :glob - bugzilla.mozilla.org team lead - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: changing the default platform and operating-system on bugzilla.mozilla.org to all / all
Lawrence Mandel wrote: +1 to Milan's suggestion. These fields are used somewhat consistently on stability and graphics bugs, which release management pays attention to. If we are going to continue with the fields, I like the idea of "Not specified" as that makes it clear that no value was set whereas "All" is currently used if the bug affects all platforms or if we don't know. thanks for the feedback. defaulting to "unspecified" instead of "all" is a great idea. i've updated the bug and will proceed along that path unless there are strong objections (keeping in mind that individual products will still be able to default to all/all should the owners desire that). -glob -- byron jones - :glob - bugzilla.mozilla.org team lead - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
changing the default platform and operating-system on bugzilla.mozilla.org to all / all
bugzilla has a set of fields, "hardware" and "operating system", that i'll collectively call "platform" in this post. their default values are detected from the reporter's user-agent string when a bug is created. unfortunately on bmo, the platform fields have two distinctly different meanings: the reporter's platform and the platform a bug applies to. for too long have these two conflicting meanings coexisted within the same field, leading to confusion and a field that on many bugs is wrong or useless. thanks to bug 579089 we plan on making the following changes early next week: * each product gains the ability to set their default platform * the default platform for all products initially will be all / all * a "use my platform" action will be added to enter-bug, allowing the bug reporter to quickly change from the product's default * a "from reporter" button will be visible when viewing untriaged bugs, which sets the platform to the reporter's -- byron jones - :glob - bugzilla.mozilla.org team lead - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: fine-grained filtering of bugmail
yes, that's how it should behave. - Original Message - From: "Gavin Sharp" To: "Byron Jones" Cc: "dev-platform" Sent: Saturday, 19 July, 2014 3:54:37 AM Subject: Re: fine-grained filtering of bugmail I added the following filters to my account: Any Any Iteration Any Exclude Any Any Points Any Exclude My expected behavior is: - if someone modifies the Points field -> bugmail filtered - if someone modifies the Points field and the Iteration field -> bugmail filtered - if someone modifies the Points field and adds a comment -> bugmail allowed Am I understanding how these work correctly? Gavin On Sun, Jul 13, 2014 at 11:13 PM, Byron Jones wrote: > are you tired of receiving notifications from bugzilla that you simply don't > care about? > > you can now tell bugzilla to stop clogging up your inbox with those pesky > emails via "bugmail filtering". > > > are you only interested in seeing new bugs and bug status changes in some > components you are watching? set up a filter! > > or perhaps you only want to be informed about qa related changes on bug > where you are the assignee? set up a filter! > > > see > http://globau.wordpress.com/2014/07/10/using-bugmail-filtering-to-exclude-notifications-you-dont-want/ > for more details. > > -- > byron jones - :glob - bugzilla.mozilla.org team - > > ___ > 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: fine-grained filtering of bugmail
Ehsan Akhgari wrote: On 2014-07-14, 9:50 AM, Byron Jones wrote: Ehsan Akhgari wrote: 1. Can we get a "Any direct relationship" field in the Relationship drop-down which means Assignee || Reporter || QA Contact || CC'ed || Mentoring (basically all cases except Watching)? how is that different from "not watching", which already exists? Doesn't "Not watching" also include "no relationship with the bug"? good point - file a bug please :) 3. Can we get a "All watched components" flag under Components? no, watching is your relationship with the bug, not a specific component. I'm talking about component watching here... ... i know :) component watching is the reason why you receive email, so it's covered by the 'relationship' filter. -- byron jones - :glob - bugzilla.mozilla.org team - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: fine-grained filtering of bugmail
L. David Baron wrote: On Monday 2014-07-14 21:50 +0800, Byron Jones wrote: Ehsan Akhgari wrote: 2. Can we get a field designating the creation of bugs, so that I can set things up so that I get bugmails for new bugs no matter what? one already exists, but i forgot to change the visible description to make it obvious. it's currently labeled as "bug id". bug 1036301. Does this include when a bug was moved into a component? That's effectively a "new bug" case. (And if everybody who wants to see new bugs has to write a complex filter for it themselves, some are likely to get it wrong and miss moved bugs.) "bug id"/"bug created" won't match when a bug is moved into a component. you need to use "component" as the field that was changed to match those actions. -- byron jones - :glob - bugzilla.mozilla.org team - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: fine-grained filtering of bugmail
Philipp Kewisch wrote: On 7/14/14 8:13 AM, Byron Jones wrote: Now, I got a notification for bug 1038029 where Magnus added himself as CC and also added the "regression" keyword. No comment was added. Does it take some time until the filters are applied? Shouldn't the bugmail filter have filtered out this email? that's possibly bug 1036872 (an interaction between the normal email preferences and filters). if you still see that behaviour after that bug has been fixed and deployed don't hesitate to file a bug. -- byron jones - :glob - bugzilla.mozilla.org team - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: fine-grained filtering of bugmail
Philipp Kewisch wrote: Great work on this feature, I like it! I currently have an email filter to exclude some bugmail for which I am not sure its possible to use the new bugmail filtering feature. The rule is to only deliver Devtools bugmail if its a new bug, or I am explicitly on CC. If it were possible, I guess it would be a 3 part rule: 1. Exclude all devtools bugs 2. Include if relationship is CC'd 3. Include if ??? is "New" that looks along the right path. currently to include new bugs you have to select "bug id" from the field list. within 24 hours that will change to "bug created" (existing filters won't be impacted). -- byron jones - :glob - bugzilla.mozilla.org team - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: fine-grained filtering of bugmail
Ehsan Akhgari wrote: 1. Can we get a "Any direct relationship" field in the Relationship drop-down which means Assignee || Reporter || QA Contact || CC'ed || Mentoring (basically all cases except Watching)? In the majority of cases I want the same thing to happen if I have any of these relationships to a bug. how is that different from "not watching", which already exists? 2. Can we get a field designating the creation of bugs, so that I can set things up so that I get bugmails for new bugs no matter what? one already exists, but i forgot to change the visible description to make it obvious. it's currently labeled as "bug id". bug 1036301. 3. Can we get a "All watched components" flag under Components? That way I can set up my filters so that I get a bugmail for bugs created in all of my watched components in Core and also for when their status changes but for nothing else, except for a few components I care about more... no, watching is your relationship with the bug, not a specific component. -- byron jones - :glob - bugzilla.mozilla.org team - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
fine-grained filtering of bugmail
are you tired of receiving notifications from bugzilla that you simply don't care about? you can now tell bugzilla to stop clogging up your inbox with those pesky emails via "bugmail filtering". are you only interested in seeing new bugs and bug status changes in some components you are watching? set up a filter! or perhaps you only want to be informed about qa related changes on bug where you are the assignee? set up a filter! see http://globau.wordpress.com/2014/07/10/using-bugmail-filtering-to-exclude-notifications-you-dont-want/ for more details. -- byron jones - :glob - bugzilla.mozilla.org team - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
bugzilla and performance, 2014
heet concatenation and minification improving the performance of a web applications isn't limited to focusing on server-side execution speed. due to bugzilla's extensions we ended up in a situation where bugzilla was serving multiple small css files - on bmo we loaded 17 stylesheets as part of show_bug in comparison with 5 for an installation of bugzilla without any extensions installed. similar to the issue encountered with memcached, extensions have complete control with regards to optionally loading stylesheets, which means any css concatenation and minification solution needed to be implemented at run-time. [bug 977969] does exactly that - the template passes an array of stylesheets to load to bugzilla's global header, where a hash of the array is used to find a unified stylesheet. simple minification is performed which dropped the stylesheet size from 54kb to 43kb on show_bug on bmo. stylesheet concatenation and minification support will be released with bugzilla 5.0, and has been live on bugzilla.mozilla.org since may 2014. :: database in order to address performance issues caused by bugzilla's use of the myisam table type, in march our DBAs upgraded our database cluster to mysql version 5.6. this was the result of analysis by the DBAs into replication and stability issues around our myisam table. as mysql 5.6 adds support for fulltext indexing to its innodb table type, bugzilla was able to switch away from myisam. this immediately fixed the database replication issues, and provided a noticeable performance boost to searches involving comments. :: looking forward the next large project is to update bugzilla so the bug object can use memcached on an unmodified installation without any non-default extensions enabled. for reasons previously covered it's unlikely we'll ship a version of bugzilla with this enabled by default, however this will allow sites to audit their own code (if any) and enable caching of the bug object if required. we periodically enable instrumentation and use it to identify the next set of targets for optimisation. this will continue for the foreseeable future. we also plan on to build on the css concatenation and minification work to provide the same benefits to javascript files. -- byron jones - :glob - bugzilla.mozilla.org team - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: bugzilla can now show bugs that have been updated since you last visited them
Sylvestre Ledru wrote: Just a question, in a custom search, the "Last Visit" shows 2014-06-04 05:47:42 instead of "more than an hour ago". yes - relative dates are not used in many places in bugzilla. the most visible place where they are used is the dashboard, which is where i took my screenshot from. -- byron jones - :glob - bugzilla.mozilla.org team - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
bugzilla can now show bugs that have been updated since you last visited them
thanks to dylan's work on bug 489028, bugzilla now tracks when you view a bug, allowing you to search for bugs which have been updated since you last visited them. see my blog post for more details: http://wp.me/p1JUqW-9M -- byron jones - :glob - bugzilla.mozilla.org team - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Non-technical comments in Bugzilla
Nicholas Nethercote wrote: On Thu, Feb 13, 2014 at 1:39 PM, Botond Ballo wrote: landing - For comments that include commit URLs summary - For comments that summarize a previously lengthy discussion workaround - For comments that include a workaround for an unfixed bug spam - For comments that don't provide technical content STR - For comments (other than the description) that contain STR. Useful for locating refined or alternate STR in later comments. diagnosis - Where we understand the cause of a bug but haven't fixed it yet, for a comment that describes the cause. design - Where we know how we'd like to fix a bug, bug haven't done it yet, for a comment that describes the plan for how to fix it. Documentation of these within Bugzilla would be good. A keyword system might be too restrictive at this point, but auto-suggestions of common tags could be helpful. the tagging system's autocomplete already sorts by most-frequently-used first. documentation-wise, i suggest using a wiki rather than bugzilla itself. two other useful tags are "obsolete" and "typo", both will also cause the comment to be collapsed by default. -- byron jones - :glob - bugzilla.mozilla.org team - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: suggested reviewers for bugzilla products and components
Marco Bonardo wrote: On 18/07/2013 15:33, Byron Jones wrote: 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. Looks like most of Toolkit is missing. Is there a reason or it was just missed? any product or component which isn't listed on the modules page (https://wiki.mozilla.org/Modules) will be missing. feel free to add it. -- byron jones - :glob - bugzilla.mozilla.org team - ___ 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: Code Review Session
wow, looks like is missed quite a lot while my power was out.. a high level response from the bmo team is: a goal for this quarter is to address a lot of the review related issues. i've been working through splinter issues and fixing the easy ones (it no longer has problems with renames/copies!), and have also been scoping out the viability of replacing splinter with either review-board or webkit's system. should review-board be viable (and i hope it will be), the plan is to host a customised version of review-board, tightly integrated with bugzilla. i have a preliminary "sounds reasonable" from IT with regards to hosting, and i'm waiting on word from our security team before proceeding with a more detailed scoping exercise (bug 874767). Justin Lebar wrote: I mean no disrespect to our bugzilla maintainers, who have an impossible and largely thankless job, but bugzilla has so much baggage from the '90s, my experience is that it ruins everything it touches. We shouldn't conflate owning the PR data with integrating the PR tool into bugzilla. If we do, we risk ending up with yet another crappy non-solution to a real problem (see bugzilla interdiff, splinter integration, and so on). it's very hard to not take disrespect with you saying that we ruin everything we touch and turn it to crap. there needs to be integration between review-board and bugzilla from a security point of view (patches on secure bugs need to stay secured), as well as from a process perspective (the results of a review should be emailed to everyone involved in the bug, and the bug needs to be updated in some way). to me the way to achieve this is to continue to use bugzilla as the source of truth (ie. attach the patch to the bug), but conduct the reviews in review-board with automatic updating of the bug. -byron -- byron - irc:glob - bugzilla.mozilla.org team - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
determining release channel from javascript?
howdy, we'd like to extend bugzilla.mozilla.org to log which channel the reporter's version of firefox is using; however i can't figure out if this information is available to javascript. i initially thought about using browser/config/version/version.txt based on the version in the user-agent, however this reflects the current default channel, and not necessarily the channel the user's application is using. for example if someone downloads aurora just before the trains leave, and doesn't upgrade before filing a bug, we'd incorrectly think they are using beta. i'm interested in either the value of app.update.channel, or the value passed to configure via --enable-update-channel. is this currently available to javascript? if so, how? if not, do you think a request to expose it would be successful? thanks -- byron - irc:glob - bugzilla.mozilla.org team - ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases
Steve Fink wrote: The name "target milestone" implies an aspirational landing. Should we just change the bug template to change the name of the field? that would be difficult as other projects which use bugzilla.mozilla.org use the "target milestone" field as a .. target milestone ;) while it would be possible to change the name of that field in the show_bug template on a per-product basis, it would be difficult on other pages such as advanced search. i suspect this will cause more confusion that it would fix :( -- byron - irc:glob - bugzilla.mozilla.org team - ___ 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
