Re: Merging comm-central into mozilla-central
Noteworthy, elsewhere in this thread, I did state that while I am a MoCo paid staff member, working in Release Engineering. and while this would NOT be part of my paid duties. I *did* state that I really want this bad enough that I'd volunteer to work on and complete the Release Engineering portions as required in my free time. So while I would agree no-one in "moco Release is going to futz with it [in order to earn a paycheck]" I've said that I would commit to fixing up the Release infra if this was greenlit. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Merging comm-central into mozilla-central
, and am an employee of MoCo. >From the code complexity standpoint Mozilla Releng code would also be greatly >benefitted by the merge. Making our day-to-day easier and less cumbersome. >Though we don't deal directly with thunderbird, the ability to remove any/all >of the complexity which does would be a boon to productivity. Also we too have the "thunderbird is lower priority than everything else" mandate, to which I abide. That said, I also will heartily proclaim that I will do the releng work required by this merge (possibly including the dead-code-removal itself) in my own volunteer time. Which would allow us [decision makers] to ignore one of the few MoCo-employee-needed assumptions I've read in this thread (that is the assumption that releng needs to do changes to cope). ~Justin Wood (Callek) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Spring cleaning: Reducing Number Footprint of HG Repos
On 3/27/2014 1:11 AM, Mike Hommey wrote: On Wed, Mar 26, 2014 at 05:40:36PM -0700, Gregory Szorc wrote: On 3/26/14, 4:53 PM, Taras Glek wrote: *User Repos* TLDR: I would like to make user repos read-only by April 30th. We should archive them by May 31st. Time spent operating user repositories could be spent reducing our end-to-end continuous integration cycles. These do not seem like mission-critical repos, seems like developers would be better off hosting these on bitbucket or github. Using a 3rd-party host has obvious benefits for collaboration self-service that our existing system will never meet. How much time do we spend operating user repositories? I follow the repos bugzilla components and most of the requests I see have little if anything to do with user repositories. And I reckon that's because user repositories are self-service. Note that while user repositories are self-service on the creation side, there is no obvious way to self-service a user repo removal. I'm not in Taras's list, but after looking, I figured I had an old m-c copy with old patches on top of it. Prior to the hg migration to local disk there was (well technically still is): ssh hg.mozilla.org edit repo which allowed you to delete it. We even had/have this info on MDN. The bug exists today that the deletion does not propogate out to the local-storage webheads. ~Justin Wood (Callek) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Spring cleaning: Reducing Number Footprint of HG Repos
On 3/26/2014 9:15 PM, Taras Glek wrote: Bobby Holley mailto:bobbyhol...@gmail.com Wednesday, March 26, 2014 17:27 I don't understand what the overhead is. We don't run CI on user repos. It's effectively just ssh:// + disk space, right? That seems totally negligible. Human overhead in keeping infra running could be spent making our infra better elsewhere. Also, project branches are pretty useful for teams working together on large projects that aren't ready to land in m-c. We only use them when we need them, so why would we shut them down? I'm not suggesting killing it. My suggestion is that project branch experience would likely be better when not hosted by mozilla. It would still trigger our c-i systems. Except when you consider the disposable project branches get Level 2 commit privs needed, and that to commit to our repos you need to have signed the committer agreement, which grants some legal recompense if malice is done. These project branches run on non try based machines which have elevated rights vs what try does, and can do much much more harm if there is malice here. I for one would not be happy from a sec standpoint if we allowed bitbucket-hosted repos to execute arbitrary code this way. ~Justin Wood (Callek) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Spring cleaning: Reducing Number Footprint of HG Repos
On 3/27/2014 2:58 AM, Doug Turner wrote: Want to move to github? (0) sudo apt-get install python-setuptools (1) sudo easy_install hg-git (2) add |hggit =| under [extensions] in your .hgrc file (3) Go to GitHub.com and create your new repo. (4) cd hg_repo (5) hg bookmark -r default master (6) hg push git+ssh://g...@github.com/you/name of your repo you created in step 3 hg-git can't run without a very very custom and difficult-to-setup hg on windows. Specifically because hg uses py2exe which strips out EVERY unused python library. And even doing hg in a virtualenv is hard because you get a MUCH slower hg due to no compiled code. I have never further tested hg-git on windows after I encountered the two issues above. ~Justin Wood (Callek) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Poll: What do you need in MXR/DXR?
Erik Rose wrote: What features do you most use in MXR and DXR? Over in the recently renamed Web Engineering group, we're working hard to retire MXR. It hasn't been maintained for a long time, and there's a lot of duplication between it and DXR, which rests upon a more modern foundation and has been developing like crazy. However, there are some holes we need to fill before we can expect you to make a Big Switch. An obvious one is indexing more trees: comm-central, aurora, etc. And we certainly have some bothersome UI bugs to squash. But I'd like to hear from you, the actual users, so it's not just me and Taras guessing at priorities. What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?) If you're already using DXR as part of your workflow, what could it do to make your work more fun? Feel free to reply here, or attach a comment to this blog post, which talks about some of the things we've done recently and are considering for the future: https://blog.mozilla.org/webdev/2013/09/30/dxr-gets-faster-hardware-vcs-integration-and-snazzier-indexing/ We'll use your input to build our priorities for Q4, so wish away! Cheers, Erik Few things for me that I don't see an easy way to do on dxr.m.o right now at a glance. Search `file names` I might remember a file is called sut_lib for example, but unsure extension or where it is, but know I need to edit it! Search text strings within a specific filename wildcard, e.g. I might want a search for some method in any idl, but not care about the underlying implementation in C++ Further insight I can't easily provide unless http://mxr.mozilla.org/build and http://mxr.mozilla.org/comm-central/ is replicated at dxr, I can provide insight on what the req's are for both setups (since build/ is many repos, while comm-central is 2 large repos and a few small ones) - For me personally comm-central is less important for my testing since mozilla-central meets most of the needs in useability. ~Justin Wood (Callek) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The state of the Aurora branch
Ed Morley wrote: On 19 January 2013 15:01:09, Ehsan Akhgari wrote: dbaron posted a summary of our options on release-drivers Please can that be posted somewhere public for those of us not on release-drivers? Not seeing anything that need be kept private, I'll forward a post or two here: - Original Message - From: L. David Baron stripped To: release-drivers Sent: Saturday, January 19, 2013 4:34:34 AM Subject: extended Aurora tree closure and options for reopening (disabling testpilot extension?) The mozilla-aurora tree is currently closed (and has been since Wednesday) due to a set of permanent test failures. Failure to reopen the tree and allow fixes to land puts Firefox 20 at risk (with the risk increasing with the length of the closure). I wrote a detailed description of the situation and laid out the known options for moving forward in: https://bugzilla.mozilla.org/show_bug.cgi?id=823989#c52 (with a few clarifications in the two comments after). The prior discussion of this issue that I'm aware of is mostly in that bug and in https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.platform/fffQo85eM8Y Of the three options I present, the one that I think has the strongest support and least opposition among the developers investigating the problems is option 2: # (2) Disable the testpilot extension on aurora using the patch in # comment 48, and reopen mozilla-aurora. comment 43 says that # we're not currently running any studies using testpilot (and # also that ehsan supports this solution). I think release-drivers should be aware that this is currently the leading option; I'm not sure who should make the final call here, but probably somebody a bit more informed about testpilot than I am. (It's currently Saturday morning in London, and I plan to spend the weekend as a tourist, so I expect to be only intermittenly online today and tomorrow.) -David ___ release-drivers mailing list - Original Message - From: Alex Keybl stripped Sent: Saturday, January 19, 2013 7:36:36 PM Subject: Re: extended Aurora tree closure and options for reopening (disabling testpilot extension?) Let's move forward with option 2 to re-open the tree, and continue investigating how to find final resolution allowing test pilot to be re-enabled on Aurora. Cheng and Jinghua - please let us know when you were hoping to push out the next survey, so we can put a date on re-enabling. -Alex ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Why are there Android 4.0 opt test runs on mozilla-central and nowhere else?
L. David Baron wrote: On Saturday 2012-12-22 09:51 -0800, Daniel Holbert wrote: Mozilla-central TBPL has a row for Android 4.0 opt, which isn't available on mozilla-inbound or on Try. I was under the impression that all the tests that get run on mozilla-central are supposed to also be run on Try and Inbound. Why is this not the case for these Android 4.0 opt tests? This was a concious choice with ATeam+Releng to get a number of tests running + visible with a small number of ready devices. It is common practice to have things on try/inbound/m-c as well. In a case like large inbound merge breaks stuff on these tests and only these tests the intent was that we would simply hide the suite(s) that break and try to figure out the problem out-of-band without forcing the tree closed. I recognize we may not have communicated that plan/desire well enough. [I *believe* edmorley as our paid sheriff knew] We will work to get these enabled on inbound at the least shortly after the holiday to help avoid this problem. I'd note that if the underlying problem is that we want to test something where we're *really* constrained in number of test devices, it might be ok to not run on Try by default and not run on inbound. But it should be *possible* to run on Try via trychooser, so that when something like this happens, it can at the very least be bisected after the fact. If we can't at least do that, then the tests shouldn't be shown on mozilla-central. It is currently not possible to have an --all run *not* run a certain test type by default (aiui), furthermore since these tests come off of regular android builds, a simple -p android would also trigger them. I *believe* sfink is working on improvements in this are for us, but being able to default-limit and overall improve try capacity/use in ways like this is also on our radar/wanted. -- ~Justin Wood (Callek) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Integrating ICU into Mozilla build
Mike Hommey wrote: On Tue, Dec 04, 2012 at 07:51:21AM -0500, Justin Wood (Callek) wrote: Rafael Ávila de Espíndola wrote: Actually, ICU has several options for how its data is packaged. One option is libraries (which are not sharable between architectures, AFAIK), but another possibility is to use data package (.dat) files, which I believe *could* be shared between the 32- and 64-bit builds. getting a bit off topic, but since we don't support 10.5 anymore, can't we build just a 32 bit plugin container instead of the full browser as a universal binary? Would the plugin container need to link with ICU too? Not yet, there are supported Hardware models using 10.6 that *do not* have 64 bit avaiable. Granted they are on the older end of stuff, but it does exist. Note that apparently, this is even worse than that. 10.6 didn't enable 64 bits by default on 64 bits capable hardware. (I just figured while looking at something unrelated on my wife's mac running 10.6.8) Yes, I meant that as well, since some of these older machines are by default set like that, and no UI way to change it. I noticed this as well on the x64 mini's SeaMonkey has that are 10.6 but my research showed that x64 was unstable on that version of mini we have so I didn't turn it on :-) -- ~Justin Wood (Callek) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Minimum Required Python Version
Gregory Szorc wrote: If there are any objections, please voice them now. Can we re-post this as an entirely new thread, out of shear luck I noticed it, though its buried in the middle of my threaded view for way back in September. In a thread I have long since chosen to ignore since I knew the final outcome of that particular post (which is how I, and I know many others, read the newsgroups here). -- ~Justin Wood (Callek) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: New backout policy for Ts regressions on mozilla-inbound
Ehsan Akhgari wrote: Hi everyone, As part of our efforts to get more value out of the Talos test suite for preventing performance regressions, we believe that we are now ready to put a first set of measures against startup time regressions. We will start by imposing a new backout policy for mozilla-inbound checkins for regressions more than 4% on any given platform. If your patch falls in a range which causes more than 4% Ts regression, it will be backed out by our sheriffs together with the rest of the patches in that range, and you can only reland after you fix the regression by testing locally or on the try server. The 4% threshold has been chosen based on anecdotal evidence on the most recent Ts regressions that we have seen, and is too generous, but we will be working to improve the reporting and regression detection systems better, and as those get improved, we would feel more comfortable with imposing this policy on other Talos tests with tighter thresholds. Please let me know if you have any questions. Do we still have the bug where a test that finishes first, but is from a later cset (say a later cset IMPROVES Ts by 4% or more) would make us think we regressed it on an earlier cset if that earlier talos run finishes later? Such that we set graph points by the time the test finished, not time the push was, etc. ~Justin Wood (Callek) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moving Away from Makefile's
Jeff Hammel wrote: While a bit of an unfair example, our buildbot-configs fall into this category. IMO not unfair at all. (p.s. to stay on topic, +1 to all else you said) ~Justin Wood (Callek) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XUL Runner, and the future.
andreas.pals...@gmail.com wrote: Hi. I am curious if XUL Runner has an End-Of-Life policy? Or is it intimately connected with Firefox, i.e. as long as there is Firefox releases based on XUL there will be XUL Runner available too? The reason I ask if because I am trying to standardize it within my organization for the next 5-10 years. Thank you. DISCLAIMER: I could be incorrect, as I am answering as a community member based on my understandings, (Official people involved can correct me). XULRunner is currently an unsupported piece of software, we don't run tests for it, and we *barely* ensure it still builds. The largest reason we still build it is for the benefit of an SDK to build binary components for Firefox against. The ideal for moving forward in a supported way is to write a WebRT application that takes advantage of HTML/HTML5/Web-Technologies for your system. HTH, -- ~Justin Wood (Callek) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Increase in mozilla-inbound bustage due to people not using Try
Justin Lebar wrote: In addition, please bear in mind that landing bustage on trunk trees actually makes the Try wait times worse (since the trunk backouts/retriggers take test job priority over Try) - leading to others not bothering to use Try either, and so the situation cascades. I thought tryserver used a different pool of machines isolated from all the other trees, because we treated the tryserver machines as pwned. Is that not or no longer the case? Yes and no, the build machines are completely different the test machines -- not so much. The testers however are shared. Testers have a completely different passwords set, as well as other mitigations. The idea here is that our test machines also have no permissions to upload anyway, nor any way to leak/get sekrets. And all machines are in a restricted network environment overall anyway. So load on inbound affects *test* load on try, yes. -- ~Justin Wood (Callek) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
