Adjusting Windows 64-bit per-checkin builds (not related to nightly builds)
Hi, We're currently suffering lack of capacity on the win64 builders. I noticed that we still run win64 dependent builds for Thunderbird Firefox. I would like to disable those since they cost approximately 1/3 of our load (win32 opt/debug win64 opt). If anyone has a strong objection for this first part of the plan please let me know. I am not touching nightly updates as from the thread it seems an open ended issue (automatically update people to the 32-bit builds) besides not being my forte. On another note, there could be a tree booked for win64 and move nightly win64 users there (orthogonal to updating users to 32-bit builds) since it would allow the community control which merges from mozilla-central to take in (and back out from bad merges). We could have dep builds running on it as well as on mozilla-central [1][2]. Please let me know what you think of this second part of the post. best regards, Armen [1] In reply to John O'Duinn [:joduinn] from comment #37) tweaking summary, per bsmedberg, we'll still generate 64bit windows builds as follows: 1) generate 64bit builds on mozilla-central, but not on mozilla-inbound, m-a/m-b/m-r or any project branches ** 64bit builds would be nightly builds only, not per checkin builds [2] On 2012-12-21 4:43 PM, Benjamin Smedberg wrote: After I announced my decision to disable 64-bit Windows nightlies, there was significant negative feedback. After reviewing that feedback, and consulting with Release Engineering, I believe that we can keep a set of users happy by making a modification to the original plan. Most importantly, it seems that there are users who regularly run into the 4GB memory limits of 32-bit builds. These users often have hundreds or even thousands of tabs. These users are using the 64-bit nightlies not primarily to be part of our testing community, but because those builds are the best product available. At this point, the Mozilla project does not have the resources to actively support this use case. Making these builds, however, is not a significant burden on our Release Engineering group. Therefore I have modified my original plan in the following way: * Migrate all existing users of win64 nightly channel builds to the win32 nightly channel builds via automatic update. * Continue to build win64 Nightly builds and updates on the nightly channel. Users who need the 64-bit builds will have to download it after the migration point (date TBD). ** Change the default first-run and update page for win64 builds to explain to users that they are not supported. ** Disable the crash reporter for win64 builds ** Enable click-to-play plugins by default in the win64 builds. * Discontinue the win64 tests and on-checkin builds to reduce release engineering load. By default, do not generate win64 builds on try. * win64 builds will be considered a “tier 3” build configuration. [1] We will continue to test the win32 builds and make sure that they work well on both 32-bit and 64-bit versions of Windows. Specifically, all of our testing on Windows 8 is planned to be done on the 64-bit version of Windows 8. I do hope that the projects and developers who are interested in win64 will work together to maintain this build configuration. I am interested in hearing from volunteers who want to become the 64-bit build maintainer. I will also set up a discussion list specifically for win64 issues, if that would be valuable. --BDS Please post followups to to mozilla.dev.apps.firefox [1] https://developer.mozilla.org/en-US/docs/Supported_build_configurations ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Adjusting Windows 64-bit per-checkin builds (not related to nightly builds)
On 3/27/2013 1:19 PM, Armen Zambrano G. wrote: On another note, there could be a tree booked for win64 and move nightly win64 users there (orthogonal to updating users to 32-bit builds) since it would allow the community control which merges from mozilla-central to take in (and back out from bad merges). We could have dep builds running on it as well as on mozilla-central [1][2]. Please let me know what you think of this second part of the post. I don't think that an extra would be necessary or useful. So far, nobody has volunteered to maintain the win64 port, so having an extra tree only means that nobody would do merges and we wouldn't even have nightly regression ranges when things broke. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Moz2D Repository Creation
Hi all, Over the past year we've increased our dependencies on Moz2D (formerly known under the codename Azure), our new 2D rendering API. Currently we're using it for canvas drawing on all platforms and content drawing on Windows where using Direct2D, and in the near future we will be moving to using it for content on all platforms. From the very beginning of Moz2D development we've taken care to make sure it can be built outside of the rest of Gecko, having only dependencies on several MFBT headers. This was done to reduce the barrier for external usage and development, we've since seen this benefit us for example in Servo using Moz2D as well. In addition to that it has helped development and bugfixing by having a much faster workflow for building/testing with which bugs could be located and fixes created. Going forward we're expanding on that by ensuring the stand-alone builds and works on all platforms and becomes the defacto way of the 'first level' of testing when implementing new features or fixing bugs in Moz2D. In addition to that we're expanding on our existing stand-alone unittesting suite as well as adding a peformance testing suite, which will include microbenchmarking and support measuring performance on Moz2D drawing recordings (single-page recording support has just landed on mozilla-inbound). When moving forward we have several goals for Moz2D when it comes to the workflow: - Improve Moz2D development workflow by having faster turnaround time on builds and tests (both local and Try) - Lower the barrier for external contributors, some people have already expressed the desire to work on potential backends we do not wish to invest in ourselves, but have been deterred by the complexity of the checkout/building process. - Improve sharing between Servo/Gecko. - Reduce load on our infrastructure by building and testing only Moz2D stand-alone when a change affects only Moz2D, both on regular builds and try. As the next step in moving towards these goals and optimally supporting them the proposal is to move Moz2D into its own repository. We would use hg subrepos for this purpose, you can read more about this here (http://mercurial.selenic.com/wiki/Subrepository). The intention is that this will be done in such a way that the workflow for developers not involved in Moz2D development would essentially not change. A more detailed description of the proposal and the workflows involved can be found here (https://wiki.mozilla.org/Platform/GFX/Moz2DSubrepository) for those interested in the details. Since we believe if we go through with this it would be the first time we use a true subrepository system for a component used in mozilla-central, we'd very much appreciate any thoughts or feedback people might have on the idea. Best regards, Bas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moz2D Repository Creation
On Wed, Mar 27, 2013 at 01:42:31PM -0700, Bas Schouten wrote: A more detailed description of the proposal and the workflows involved can be found here (https://wiki.mozilla.org/Platform/GFX/Moz2DSubrepository) for those interested in the details. Since we believe if we go through with this it would be the first time we use a true subrepository system for a component used in mozilla-central, we'd very much appreciate any thoughts or feedback people might have on the idea. Relatedly, https://bugzilla.mozilla.org/show_bug.cgi?id=853749#c11 Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moz2D Repository Creation
On 28/03/13 10:03, Justin Lebar wrote: Since we believe if we go through with this it would be the first time we use a true subrepository system for a component used in mozilla-central, we'd very much appreciate any thoughts or feedback people might have on the idea. Have you thought about how this hg subrepo will interact with the git mirrors of m-c? Using m-c git isn't just for contrarians these days: B2G relies heavily on git clones of m-c. So we need to make sure this will work properly. Why not just put Moz2D in a git repo? http://mercurial.selenic.com/wiki/Subrepository#Git_subrepositories ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moz2D Repository Creation
On 3/27/13 2:03 PM, Justin Lebar wrote: Since we believe if we go through with this it would be the first time we use a true subrepository system for a component used in mozilla-central, we'd very much appreciate any thoughts or feedback people might have on the idea. Have you thought about how this hg subrepo will interact with the git mirrors of m-c? Using m-c git isn't just for contrarians these days: B2G relies heavily on git clones of m-c. So we need to make sure this will work properly. hg-git (the tool we use to synchronize Mercurial and Git repos) supports subrepos. Although, I'm not sure how well it works. And, the side-effect there is that you are forcing submodules on Git users. I haven't met many Git users who enjoy submodules, myself included. submodules are so bad that a whole class of wrapping tools (like repo [1]) have sprung up to plug the deficiencies. [1] https://code.google.com/p/git-repo/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moz2D Repository Creation
On Wed, Mar 27, 2013 at 9:42 PM, Bas Schouten bschou...@mozilla.com wrote: As the next step in moving towards these goals and optimally supporting them the proposal is to move Moz2D into its own repository. We would use hg subrepos for this purpose, you can read more about this here (http://mercurial.selenic.com/wiki/Subrepository). The intention is that this will be done in such a way that the workflow for developers not involved in Moz2D development would essentially not change. Did you take note of the warnings and recommendations in the wiki regarding subrepository usage? I used them for a while at work, some time ago, and it's... different. Theoretically it's all simple and nice, but there end up being corner case that don't work so well. And what with the git conversions that some people seem to prefer, that would all be even more complex. I'd recommend thinking this over a bit, and maybe just using the NSS model instead, or some method to pull in a fixed revision/tarball via a build system or similar feature. Cheers, Dirkjan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moz2D Repository Creation
hg-git (the tool we use to synchronize Mercurial and Git repos) supports subrepos. Although, I'm not sure how well it works. Well, we should definitely figure this out before we move forward with this plan. If the hg support for git repos is decent, that might be a better way to go, since then we'd have one fewer repo we needed to mirror for B2G's purposes. Assuming that hg-git is happy with git submodules. :) I haven't met many Git users who enjoy submodules, myself included. Git submodules suck, but so does importing library code via cp, as we do now. :-/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moz2D Repository Creation
On Thu, Mar 28, 2013 at 9:42 AM, Bas Schouten bschou...@mozilla.com wrote: - Improve Moz2D development workflow by having faster turnaround time on builds and tests (both local and Try) - Lower the barrier for external contributors, some people have already expressed the desire to work on potential backends we do not wish to invest in ourselves, but have been deterred by the complexity of the checkout/building process. - Improve sharing between Servo/Gecko. - Reduce load on our infrastructure by building and testing only Moz2D stand-alone when a change affects only Moz2D, both on regular builds and try. Seems to me that of those goals, only lower the barrier for external contributors actually *requires* Moz2D to be in a separate repository. Is that right? Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moz2D Repository Creation
Personally I don't care if we use Git or Mercurial, what I do feel fairly strongly about is that whatever we do for Moz2D runs on our own infrastructure. If that infrastructure supports git I have no issues with it being in git. Although I've done my testing with hg subrepos only. For what it's worth I personally find our mix of mercurial and git extremely disturbing, and this once again goes to show the amount of problems that come from such an architecture. I'd find it quite sad if the fact we're in this situation would block progress on this front. As to subrepository functionality, they seem to work well for our purposes, it's true that some complexities arise if you would like to do certain operations across repository boundaries but I didn't see a lot of cases where we'd actually want that. For what it's worth, I've worked with SVN externals before and found them quite nice to work with. But I must admit my experience with hg subrepos is limited to the testing I did. I've heard stories that mercurial subrepos work a lot better than git submodules, however I have even less experience with the latter. One argument for hg subrepos is that their type of functionality is pretty much -exactly- what we want/need for a great experience. This could be true for git submodules as well, but I have no idea if it is. Bas - Original Message - From: Justin Lebar justin.le...@gmail.com To: Gregory Szorc g...@mozilla.com Cc: Bas Schouten bschou...@mozilla.com, dev-platform dev-platform@lists.mozilla.org Sent: Wednesday, March 27, 2013 10:06:56 PM Subject: Re: Moz2D Repository Creation hg-git (the tool we use to synchronize Mercurial and Git repos) supports subrepos. Although, I'm not sure how well it works. Well, we should definitely figure this out before we move forward with this plan. If the hg support for git repos is decent, that might be a better way to go, since then we'd have one fewer repo we needed to mirror for B2G's purposes. Assuming that hg-git is happy with git submodules. :) I haven't met many Git users who enjoy submodules, myself included. Git submodules suck, but so does importing library code via cp, as we do now. :-/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moz2D Repository Creation
I would argue this is probably true. As I've talked to a developer from a large third party where the discussion of if they would try to adjust their work to Moz2D literally ended at: 'I have to check out -all- of firefox? How big is that 2 Gig or something?' I think it's certainly the largest practical and mental barrier. Best regards, Bas - Original Message - From: Robert O'Callahan rob...@ocallahan.org To: Bas Schouten bschou...@mozilla.com Cc: dev-platform dev-platform@lists.mozilla.org Sent: Wednesday, March 27, 2013 10:14:35 PM Subject: Re: Moz2D Repository Creation On Thu, Mar 28, 2013 at 9:42 AM, Bas Schouten bschou...@mozilla.com wrote: - Improve Moz2D development workflow by having faster turnaround time on builds and tests (both local and Try) - Lower the barrier for external contributors, some people have already expressed the desire to work on potential backends we do not wish to invest in ourselves, but have been deterred by the complexity of the checkout/building process. - Improve sharing between Servo/Gecko. - Reduce load on our infrastructure by building and testing only Moz2D stand-alone when a change affects only Moz2D, both on regular builds and try. Seems to me that of those goals, only lower the barrier for external contributors actually *requires* Moz2D to be in a separate repository. Is that right? Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moz2D Repository Creation
On Thu, Mar 28, 2013 at 11:45 AM, Bas Schouten bschou...@mozilla.comwrote: I don't think it works that way. At least it doesn't for me, these time issues don't work that way. There's a context switch involved, those are expensive and there's the feeling of pulling in 2.5 gigs+ onto your hard drive to do something small, for someone else really, not because you get paid for it. Especially when you're for example on a conference with a poor network connection. As another example, currently pushing to try is a very conscious decision for me. Is this test result worth it if it's going to take me 4 hours to get the results on all platforms? I'll have to look at it again tomorrow, maybe I should look a little more if I've done everything to make sure it works. Because I know that by pushing that try run I'm going to put a lot of burden on our infrastructure to see if a small change compiles on all platforms. But pushing to try is something you do a lot. Cloning Moz2D is something you probably only do once. And you probably won't do it at a conference. Additionally all -other- operations on a larger repository are a lot slower, things like top-level diffs, updates, etc. They take seconds or less on small repository, every step of your workflow is more efficient in a more isolated environment. Bisecting is only a small example of this, bisecting inside a small repository with a fast build/test is a process that's done very quickly and is very easy to justify timewise. Bisecting mozilla-central is a hard task that takes a lot of time. Mainly because you have to build all of mozilla-central. Standalone builds and tests of Moz2D would be great and we can do that without putting it in its own repository. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moz2D Repository Creation
On 3/27/13 11:38 PM, Joshua Cranmer wrote: On 3/27/2013 5:25 PM, Bas Schouten wrote: I would argue this is probably true. As I've talked to a developer from a large third party where the discussion of if they would try to adjust their work to Moz2D literally ended at: 'I have to check out -all- of firefox? How big is that 2 Gig or something?' I think it's certainly the largest practical and mental barrier. How hard would it be to add support in mercurial for checking out a specific directory within a repository? I personally prefer this solution. comm-central does it successfully with its client.py and it hasn't been annoying for me. Philipp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moz2D Repository Creation
Thanks a lot for thinking along here from the RelEng side of things! - Original Message - From: Alex Keybl ake...@mozilla.com To: Bas Schouten bschou...@mozilla.com Cc: dev-platform dev-platform@lists.mozilla.org Sent: Wednesday, March 27, 2013 11:25:14 PM Subject: Re: Moz2D Repository Creation Can you clarify the main motivation behind using a subrepo over a Tier 1 dev branch like m-i or services-central? Mimicking what we already do elsewhere would have less process/infra change overhead, and my intuition tells me that per-checkin builds/tests could be configured specifically for that repo. Perhaps we should be focusing mostly on your point about Improv[ing] sharing between Servo/Gecko though. The main motivations would be: - Reduced tree size (for clone/pull/update/etc.) - Easier bisection within the specific Moz2D code. - Cleaner merging system (i.e. rather than merging, it would just be a revision tag update in m-c) Assuming we move forward with a subrepo, a few thoughts: * Whatever the branching model becomes, it sounds like it'll end up being around merges. Just let us know what you'd like us to do at m-c-m-a and upon subsequent merges. No problem there. Nothing should change for that, m-c - m-a would just take the currently tagged revision along with it, and that would remain the revision used. For upstreaming patches the process gets a tiny bit different, see also your point below this one. I've added some of my own thoughts to the wiki page. * We'll need to decide how to handle approvals - whether to gate at landing to a branched subrepo, or updating the changeset in the main repo. Just requires some discussion. * Somebody (engineer, sheriff) would need to make sure that after landing to a subrepo branch, a version of Firefox is marked as fixed once it the changeset starts being referenced from the main repo. Yeah, this is an interesting point. The question is if it's defined fixed by being fixed on Moz2D or in Firefox, probably the latter is best. As for impact to QA and investigations, I agree that the change should be fairly minimal. Since we'd still like the help of contributors and QA in bisecting a day's worth of Moz2D changes, new documentation may be necessary. Indeed, a day (or a week) worth of Moz2D changes will be a lot easier to bisect though! :-) And could even be done within m-c where you'd for example only have to rebuild gfx/2d and layout/media, as long as your bisection doesn't include API changes. This would be one of the advantages of the separation listed above. -Alex Bas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
T pushes to try
Inspired by https://blog.mozilla.org/nnethercote/2013/03/27/an-interesting-use-of-the-try-server/ , I verified that T pushes do indeed work, and I think they are a viable infrastructure-saving alternative to the usual try: -b do -p all -u all push. A T push is a try push that builds on all platforms and runs all tests on a single platform. (The 'T' is from the shape of the resulting tbpl output.) The canonical example would be try: -b do -p all -u all[x64] -t none which will do the full test series on linux64 machines (which currently means a mixture of our Fedora and AWS's Ubuntu systems.) If you (or the current load) are more osx-centric, you could use try: -b do -p all -u all[10.8] -t none I think these pushes should do a decent job of balancing the completeness of results with infrastructure demand. Plus, it gives the warm fuzzy feeling of staving off the heat death of the universe by (up to) a few seconds! Yes, it does depend on a mostly undocumented try syntax feature from bug 802937. I've at least added these example pushes to https://wiki.mozilla.org/ReleaseEngineering/TryChooser. If I (or someone else) changes how the square bracket syntax works, I'll endeavor to keep these specific examples working. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: T pushes to try
On 3/27/13 8:08 PM, Steve Fink wrote: Yes, it does depend on a mostly undocumented try syntax feature from bug 802937. I've at least added these example pushes to https://wiki.mozilla.org/ReleaseEngineering/TryChooser. Adding either a link to that, or examples directly, to http://trychooser.pub.build.mozilla.org/ would be awesome... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moz2D Repository Creation
On 03/27/2013 07:37 PM, Robert O'Callahan wrote: I predict that eventually we'll want to switch mozilla-central to git. (I'm not in favour of it, but hg is not the DVCS of the future.) So, git users not liking git's subrepositories gives me pause and I think it's imperative to consider the situation of git users now and after a hypothetical mozilla-central switch to git. I've investigated submodules before to try to solve this exact problem and came away pretty unimpressed. This was nearly 3 or 4 years ago, but I doubt things have changed much. A quick search suggests that other people are also similarly unimpressed with submodules, such as the post at http://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/ I suspect the answer here would be to choose a solution that is easily convertible to a repo-style setup. We already have experience in-house with repo due to Android and B2G and it seems to mostly do what we would be aiming for with this project. On the main note (which I already brought up on IRC): I would be very interested in seeing whether this experiment succeeds or not, as I'd like to get to the stage where the entire Skia source tree inside mozilla-central is just a checkout of upstream Skia, whether that's via submodules or repo or whatever. George ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
