[no subject]
Yesterday a mass change was applied to bugzilla to move a set of bugs to a RESOLVED: INACTIVE state. Dealing with inactive bug reports has been a contentious issue in the past. While I think it’s time for us to revisit that issue and make different choices than we have in the past, a change of this magnitude shouldn’t have been applied to the live bugzilla database before sufficient discussion happened. The decisions about what constituted an active bug, how that categorization should be reflected in the database, and whether different subsets of bugs need different policies were not discussed. Therefore, we will reverse this change. We are testing the script in https://bugzilla.mozilla.org/show_bug.cgi?id=1464312 to make sure the revert goes well and once we have confidence that the script is working as expected a note will be sent to confirm the timing. To address some of the questions that have come up: Q: What will happen to the bugs that were moved to INACTIVE and then re-opened? A: If the last change to a bug was NOT the automated change to INACTIVE, then nothing will happen to the bug when the reversion script is run. Q: What constitutes a last change? A: *Any* modification to a ticket. If there are bugs you wanted to revert and were not, we’ll work with you to fix it. Respond to this thread and we will address the problem. Q: What will happen if I re-triaged bugs that were moved and decided to leave a subset of them Closed:Inactive? A: Place a comment in https://bugzilla.mozilla.org/show_bug.cgi?id=1464312 to request that your bugs are left alone. Q: Will bugmail be sent as a result of the revert? A: No. Q: What will happen to the last modified date? A: Reverting will restore the last modified date. Q: How long with the revert process take? A: Once it is kicked off, it should take hours to complete. An email will be sent once it starts and a notice once it is complete. We recognize that this move impacted a lot of people, and we don’t want to make things worse. We’re trying to make this happen as quickly as possible, but we want to take enough time to make sure it happens as smoothly as possible. Thank you for your patience while we work this out. Thanks, -dave ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Firefox Architects
We don't have a lot of people whose responsibility extends to the entire Firefox frontend. Most of us are focused on individual pieces of our large codebase. Meanwhile, we have a set of large technical challenges ahead of us. In particular, gofaster and figuring out what comes after XUL are going to be sweeping changes that affect large swaths of code. We are asking Dave Townsend, Richard Newman, Rob Helmer, Mark Hammond, and Robert Strong to explicitly take over technical stewardship of the Firefox products. Their responsibilities will be: * Document and build consensus around larger projects that affect Firefox products. * Help resolve technical issues that cross functional areas of the project. * Provide a point of consistent technical decision making. * Be a point of contact for and coordinate cross-technology projects with other Mozilla groups such as Platform and Content Services. * Be available to technical contributors for guidance, mentoring, etc. This may look a lot like Module Ownership - this is no coincidence. Mark Finkle (as Firefox Mobile module owner) and I (as Firefox Desktop module owner) will be delegating a lot of the technical responsibility for those modules to that group. It may also remind some folks of the Super Reviewers. It’s similar to that in spirit (a group of people charged with a global view of the product) but not in mechanics (no sr? flags, and limited to the Firefox frontend modules). This isn't a permanent appointment. We've asked these people to help get us started working through the gofaster and deXULinisation initiatives, but we'll cycle people in an out as events warrant. Nor do we expect these people to do it alone. We expect them to be working closely with all the engineers on the team. Thanks to the Firefox Architects for stepping up. -dave ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: ESLint checks are now running on the nightly trees on checkin
This is great, big thanks to everyone involved. -dave On Thursday, January 14, 2016, Dave Townsend wrote: > Just a heads up, a full ESLint check of the tree is now being run on > every checkin to mozilla-central or the other integration branches. > The check is also available on tryserver [1], you can run it locally > with "mach eslint" or why not make life easy and install the mercurial > extension [2]. > > Not many rules are enforced yet so mostly this is stopping you from > using non-standard JS and preprocessing. > > All hail the mighty releng folks who have made it so ridiculously easy > to prototype and deploy new taskcluster tests! > > [1] try: -b o -p eslint-gecko > [2] http://www.oxymoronical.com/blog/2015/12/Running-ESLint-on-commit > ___ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Voting in BMO
We don't use bugzilla votes as a strong signal for prioritization on devtools. We do actually keep an eye on votes in some other channels ( ffdevtools.uservoice.com), but I don't think anyone on devtools would object strongly to votes going away in bugzilla. -dave On Tue, Jun 9, 2015 at 3:48 PM, Axel Hecht wrote: > I recall that at least one group actively uses votes to prioritize stuff. > > I can't really tell which one, I'm leaning towards devtools, but I don't > have any data to back that up. > > I mostly remember because I was surprised. > > Also, for a component like devtools, I can see how it'd make sense. > > Axel > > > On 6/10/15 12:09 AM, Mark Côté wrote: > >> In a quest to simplify both the interface and the maintenance of >> bugzilla.mozilla.org, we're looking for features that are of >> questionable value to see if we can get rid of them. As I'm sure >> everyone knows, Bugzilla grew organically, without much of a road map, >> over a long time, and it experienced a lot of scope bloat, which has >> made it complex both on the inside and out. I'd like to cut that down >> at least a bit if I can. >> >> To that end, I'd like to consider the voting feature. While it is >> enabled on a quite a few products, anecdotally I have heard >> many times that it isn't actually useful, that is, votes aren't really >> being used to prioritize features & fixes. If your team uses voting, >> I'd like to talk about your use case and see if, in general, it makes >> sense to continue to support this feature. >> >> Thanks, >> 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
