Re: Phabricator Update, July 2017
Mark Côté wrote: > It was announced in May > (https://groups.google.com/forum/#!topic/mozilla.tools/4qroY2Iia9I), > linked to in this forum: > https://groups.google.com/d/msg/mozilla.dev.platform/qh5scX3Gk2U/xCWe8jrOAQAJ I stand corrected, thanks. I would've thought that'd be put in moz.dev.planning or at least cross-posted since it is a planning issue. Edmund ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Phabricator Update, July 2017
Hi Joe, I just want to publicly apologize for being sarcastic in my original post to you. I could've found a better voice and the frustration clouded my judgement. I'm sorry. Edmund ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Phabricator Update, July 2017
Mike Hoye wrote: > > Given that we've been talking about this stuff for years now, I think > it's very clear that we haven't come to this point by "somebody at the > top issuing an edict that they want something modern"; the decision to > commit to Phabricator was ultimately announced on May 11th, and that > decision wasn't made unilaterally or lightly. It's hardly fair to say that "we've been talking about this stuff for years now" when this is the very first time it's been posted. There was no public notification of the intention of doing away with splinter/MozReview. Sure, there may have been talks but were they public and not just hidden in some obscure thread? > > We've been discussing how to improve our tooling and processes in open > forums for years now, most frequently on dev-platform. Despite that, > it's true that a lot of the major influences of this decision have been > mostly invisible to people who aren't involved in the day to day work on > infrastructure and tooling, in the way that icebergs are mostly invisible. Not exactly a good analogy there, considering icebergs can also sink ships. So this discussion has been pretty much invisible from people who use the tools and only for the select few. > Some of the things that haven't made it into this thread that have > influenced this decision include: > > - a real and pressing requirement to update our commit access policies > and practices, and backstop them with reliable tooling (a discussion you > participated in, as I recall), Yes. I did participate in that. Though I'm not entirely sure what came off that discussion. > - the significant engineering burdens (including opportunity cost and > bus-factor risk) of being the sole owner/user of a major piece of > infrastructure software that's not our core product, and Oh hell yeah. This truck/bus factor is a definite PITA, and I applaud any effort in fixing this. > - the much more pernicious set of hidden costs we incur from _failing_ > to standardize on certain tools and processes. I agree as well. > > It's a very serious drag on product development and contributor > participation if everyone - paid senior engineers and new contributors > alike - needs to use _this_ tool and process and coding style (and and > and) to participate in one part of the project, and _that_ etc. etc. to > participate in another. Or, sometimes, even other corners of the same > codebase. Oh... hell yeah. You've mentioned quite a lot of pain points in the whole process, and I certainly agree with them. However, it would've been a better process if there was some sort of public declaration of intention of moving to a tool which would streamline the whole review and commit process. While there may have been a smattering of discussions here of commit policies, there wasn't a concise, for lack of a better word, glue to point out that there was going to be this change. The point is this. We have bugzilla and having a review process that enable people to review patches without needing to jump to another tool, would be more effective than needing to jump from one tool (bugzilla) to another one. If Phabricator does the job well, then so be it. Thank you for your clarifications, Mike. Edmund ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Phabricator Update, July 2017
Joe Hildebrand wrote: > I'm responding at the top of the thread here so that I'm not singling out any > particular response. > > We didn't make clear in this process how much work Mark and his team did > ahead of the decision to gather feedback from senior engineers on both Selena > and my teams, and how deeply committed the directors have been in their > support of this change. Really? So? What exactly is your point? 1) That Mark and his team put a lot of effort? 2) You gathered feedback from senior engineers? 3) The directors are deeply committed with this change? So you've asked senior engineers because they do the brunt of the reviews. Is this the new transparent way about selecting a tool which *everyone* uses and not just the selected few? [No... I'm not complaining because I wasn't selected. I'm complaining because Mozilla is doing a pdf.js with Splinter.] Don't get me wrong. I have absolutely no doubt Mark and his team placed a lot of effort in setting this up. Just as a lot of effort was put behind MozReview and Splinter. But the thing is, when someone at the top issues an edict that they want something 'modern', someone has to put the effort in, so saying what you said is just a red herring. It doesn't explain the rationale or even the criteria in selecting the new tool. > > Seeing a need for more modern patch reviewing at Mozilla, Laura Thomson's > team did an independent analysis of the most popular tools available on the market today. Working with the NSS team to pilot What exactly does a "more modern patch reviewing" mean? What is the set of criteria that would deem a tool to be 'modern'? All I am seeing is what I saw with PDF.js; that is, Mozilla is moving away from in-house solutions to external ones. Fine. That is Moco's choice. And yes, I have used Phabricator before so I know what it looks like. I'm just disagreeing with the necessity of setting up an external tool to Bugzilla's Splinter. But I suppose, I'll wait and see how this pans out. Perhaps two years down the road, something more 'modern' will come along and we'll go through this again. A company such as Mozilla that's purporting to support choice is certainly not really practicing what it preaches. In this specific example, we have seen Mozilla break the 8th edict of the Mozilla Manifesto; that is: "Transparent community-based processes promote participation, accountability and trust." The choice of Phabricator was neither transparent, nor community-based. So how is this going to promote participation, accountability and trust? Good luck with that. Again... I will wait and see how this Phabricator pans out. Worse comes to worse, I just copy and paste the code and review it in the comment section. > Therefore, I would appreciate that if you feel the need to further comment on > this thread, we focus on what can be done to make this transition successful, > rather than appearing to be standing in the way of progress. "standing in the way of progress"? Ouch. That is really harsh. Has that "if you're not with us, you're against us" type of vibe. Seriously... was that even necessary? Well... if that's the case, I'll just wait until gets released and have a go again. Edmund ___ 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
Mike Connor wrote: > (please direct followups to dev-planning, cross-posting to governance, > firefox-dev, dev-platform) > > > Nearly 19 years after the creation of the Mozilla Project, commit access > remains essentially the same as it has always been. We've evolved the > vouching process a number of times, CVS has long since been replaced by > Mercurial & others, and we've taken some positive steps in terms of > securing the commit process. And yet we've never touched the core idea of > granting developers direct commit access to our most important > repositories. After a large number of discussions since taking ownership > over commit policy, I believe it is time for Mozilla to change that > practice. > > Before I get into the meat of the current proposal, I would like to outline > a set of key goals for any change we make. These goals have been informed > by a set of stakeholders from across the project including the engineering, > security, release and QA teams. It's inevitable that any significant > change will disrupt longstanding workflows. As a result, it is critical > that we are all aligned on the goals of the change. > > > I've identified the following goals as critical for a responsible commit > access policy: > > >- Compromising a single individual's credentials must not be sufficient >to land malicious code into our products. >- Two-factor auth must be a requirement for all users approving or >pushing a change. >- The change that gets pushed must be the same change that was approved. >- Broken commits must be rejected automatically as a part of the commit >process. > > Aside for the first one, the other items seem to be mere 'implementation/application details', rather than actual goals. - Protect Firefox repositories to the best of our abilities and resources availability by implementing a set of rules and factors to prevent unauthorized access/modifications to the core content. > In order to achieve these goals, I propose that we commit to making the > following changes to all Firefox product repositories: By all Firefox product repositories, I'm assuming mainly m-*, and integration/m-i? And with this new proposed process, this means the doing away of integration/m-i as it would be superfluous if an autoland-esque repo is used. What about other repositories? Tier 2, etc.. i.e. comm-*? > > >- Direct commit access to repositories will be strictly limited to >sheriffs and a subset of release engineering. > - Any direct commits by these individuals will be limited to fixing > bustage that automation misses and handling branch merges. >- All other changes will go through an autoland-based workflow. > - Developers commit to a staging repository, with scripting that > connects the changeset to a Bugzilla attachment, and integrates > with review > flags. So m-i is obsoleted. Autoland is the defacto push repo? 1) Developer submits a patch to bugzilla or reviewboard 2) it gets reviewed and/or approved 3) it then gets pushed to autoland [tbh, I don't know how autoland works, so does someone push to autoland, or does bugzilla do it for us? -rhetorical question.. can find out off-list] 4) sheriffs watch the autoland tree and backout whatever bustages happen and every so often, they merge autoland to m-c. If patches need to be uplifted, they are done by sheriffs. So we're pretty much back to the similar vein of m-* and mozilla-inbound (except now, it's autoland). Is this the gist of it? Edmund ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
Steve Fink wrote: > On 12/20/2016 06:20 PM, Edmund Wong wrote: >> Richard Barnes wrote: >> >>> Broadly speaking, this plan would entail limiting new features to >>> secure >>> contexts, followed by gradually removing legacy features from insecure >>> contexts. Having an overall program for HTTP deprecation makes a clear >>> statement to the web community that the time for plaintext is over -- it >> There is nothing wrong with plaintext just as long as it isn't something >> credential-like. Also, what you're doing will only make a clear >> statement to the web community that you are forcing something on them >> and limiting THEIR choices of broadcasting their information as they >> see fit. >> >> IOW, "deprecating HTTP" is not a good idea. > > If I have a browser exploit that I can embed in a
Re: Intent to deprecate: Insecure HTTP
Richard Barnes wrote: > There's pretty broad agreement that HTTPS is the way forward for the web. > In recent months, there have been statements from IETF [1], IAB [2], W3C > [3], and even the US Government [4] calling for universal use of > encryption, which in the case of the web means HTTPS. > > In order to encourage web developers to move from HTTP to HTTPS, I would > like to propose establishing a deprecation plan for HTTP without security. With all due respects, the HTTP->HTTPS *isn't* entirely a web developer's choice; but the web server administration choice (unless the person is wearing both hats). Just because the US Government is calling for encryption (i.e. HTTPS over HTTP), it doesn't mean people can and/or will do it. Why? Why do people need to be forced to use HTTPS when it's overkill for their website? I mean.. would a run-of-the-mill-with-no-shopping require HTTPS? Like, i.e http://www.ambrosia-oysterbar.com/catalog/index.php HTTPS is a secured method of transporting information. For the above website, https would mean absolutely no sense and would be akin to getting BRINKS to transporting a T-bone steak dinner to you. Can you do that? Sure possibly if BRINKS doesn't ignore you right out. Why would you do that? Like everything, HTTPS is a tool and it's a bad idea to force people to use HTTPS when they don't need it. When do they need it? Who decides when they need it? Certainly not you, or anyone else other than themselves. So like the NetworkInterface issue... please stop wasting resources doing these 'busy' things when you can be doing something else that gives more choice to the user. I mean.. doing the things right vs. doing the right things and I believe it was the late Peter Drucker that wrote that. > Broadly speaking, this plan would entail limiting new features to secure > contexts, followed by gradually removing legacy features from insecure > contexts. Having an overall program for HTTP deprecation makes a clear > statement to the web community that the time for plaintext is over -- it There is nothing wrong with plaintext just as long as it isn't something credential-like. Also, what you're doing will only make a clear statement to the web community that you are forcing something on them and limiting THEIR choices of broadcasting their information as they see fit. IOW, "deprecating HTTP" is not a good idea. :ewong ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: NetworkInformation
Eric Rescorla wrote: > > I'm also concerned that this spec does not seem to take into account > multipath or multihoming, both of which seem relevant here. Say that I have > a device with both a cellular and WiFi link and I attempt to use both of > them in some fashion (depending on the remote IP address), what should I be > reporting for Network Connection? Why does it matter to Firefox what network connection I use? I would understand Firefox needing telemetry on system specs and how it runs against this spec, but network information? Really? I mean... what's wrong with: Firefox: Can I connect to the Internet? Yes: Great. Proceed to connect. No: Cannot connect. Display message. Wait for user to fix issue. Why does Firefox (or anyone other than me) CARE I have 1, 2, or a billion network interfaces or what type they are? Its job is to browse the Internet. THAT'S IT. If Chrome wants to add it, that's their business. So, in conclusion, Firefox or, in fact, ANY browser, has NO business knowing how many connections I have and what types they are. Mobile browsers should act just like desktop browser. Can it connect to the website? Yes or No. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MXR permanently offline, please transition to DXR
Mike Hoye wrote: > On 2016-06-24 6:20 AM, Philip Chee wrote: >> >> I wonder what is necessary to set up an instance of MXR (for comm-*) on >> our own server (or vps). I would guess PERL, hg, and a Linux VM. > I've got the impression that comm-* has enough rocks to push up the > legacy-stack hill already. > Correction: boulders. :P ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MXR permanently offline, please transition to DXR
Ms2ger wrote: > On 22/06/16 20:30, Lawrence Mandel wrote: >> Mozilla Cross-Reference, better known as MXR (https://mxr.mozilla.org), was >> taken offline on June 13, 2016, to investigate a potential security issue. >> After careful review of the codebase, we have decided to accelerate the >> planned transition from MXR to its more modern equivalent, DXR ( >> https://dxr.mozilla.org), instead of bringing MXR back online. > > I wish the years of complaining about MXR had led to an equally useful > replacement for it by now. > > Sad to see it go. Ditto. It's been my mainstay for searching code... couldn't dxr have a similar ui and does it have to default to mozilla-central? Edmund ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Merging comm-central into mozilla-central
Ehsan Akhgari wrote: > On 2015-10-23 2:17 PM, Joshua Cranmer wrote: >> It's a relatively easy matter to fix the first; the second is harder to >> do for all contributors. I've been told it's a coming feature, but I've >> been told this for a while. >> >> I also wonder why you have a peculiar insistence that comm-central code >> must not appear to any contributor, given the continued existence of >> "stuff that Firefox doesn't care about" in mozilla-central, such as >> support for tier-3 platforms (do we still have QT code in the tree) or >> xulrunner. The mere presence of code in a codebase has proven to be >> horribly insufficient to guarantee that people care about maintaining >> it--history has time and time and time again shown that any code that >> doesn't impact Treeherder results *WILL* get broken. (Easiest case in >> point: try building without unified files.) > > What matters more about what code remains in the tree and what code > doesn't is whether it's maintained. We have in the past removed code > for these tier3 ports and products when they have been unmaintained > (example: bug 969757) and we should be doing more of that. > > What are the long term plans for the Thunderbird and SeaMonkey community > to maintain their code, if it gets merged into m-c? On tb-planning I > see ongoing discussions about moving to other platforms such as > Electron, or the broader doubts about how Thunderbird wants to deal with > future upcoming changes such as the current add-ons? The SeaMonkey community is still maintaining the code; it's just that we haven't been able to do it that effectively the past year due to the fact that we're behind in the infrastructure setup and we've been trying to keep our tree unbroken due to changes in m-*. That said, I really appreciate those who also lent a hand to help SeaMonkey's trees become green(or relatively green with a hint of orange and red). As for the long term plans, I'll wait for one of the SeaMonkey council members to comment on that; but I believe we are determined to maintain the SeaMonkey code. Edmund Edmund ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing MozillaBuild 2.0.0 Release
Ryan VanderMeulen wrote: After a long wait, I am pleased to announce the final release of MozillaBuild 2.0.0. http://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32/MozillaBuildSetup-Latest.exe Much has changed since version 1.11.0, hence the change in major version number. It is STRONGLY advised that this not be installed over top of a previous installation. Awesome! Thanks! OTHER UPDATES/ADDITIONS/REMOVALS * Removed SVN 'bout time. :) Edmund ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
sr flag question
Hi, Recently I read Dave Townsend's thread about Super-review, what shall we do with you? and realized there wasn't any conclusion to that. As a relative new dev, I think it is vital to have a clear distinction as to when a sr is required. I've only done a few patches that required sr (c-c stuff) and I don't recall any m-c patches I did required sr (or not that I know of). But I feel that as I gain more understanding of the code, I'll encounter the sr flag more frequently. So I feel it is important that a new dev understands clearly what the sr? flag is and under what conditions it is required. To veteran devs it might be very evident, but it isn't for a new dev, at least, not to me. My understanding is that a sr flag is needed when there's an API change or a UI change. What constitutes an API change or at least, to what extent would an API need to change in order to require a sr? For example, for the EnumerateForwards/Backwards removal bug (bug #819940), would it have qualified as an API change that required sr? The bug didn't explain the rationale for the removal so I'm assuming it was important or required. Thanks for any clarifications, Edmund ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
