>From what you've said, I think the next step will be submitting a patch --
https://firefox-source-docs.mozilla.org/contributing/how_to_contribute_firefox.html#to-submit-a-patch
Your strategy for choosing a reviewer is not a bad one. Choosing a
reviewer can be difficult! If that person is not th
Hi Sanchit --
We have a tool for that! https://codetribute.mozilla.org/
As you'll see, there are bugs from a wide variety of projects, including
but not limited to Firefox. A fact of software is "there are always bugs",
so there's plenty to do on Firefox, too. You'll note that not all of the
"
The Taskgraph submodule covers the in-tree code to generate tasks for
Firefox and other projects, including implementing cron tasks and actions.
It also covers management of the relevant Taskcluster resources, most
critically the scopes afforded to people and repositories and ensuring the
integrity
Just a quick follow-up to say that ci-admin and ci-configuration are now
"live" and being actively used to maintain CI-related Taskcluster resources.
What used to be handled with a "service request' to the TC team can now be
handled with a bug and a phabricator review request.
I look forward to s
We have been working on a new approach to configuring the Firefox-CI
installation of Taskcluster to suit Firefox's needs. If you've ever needed
a scope assigned to a repository, wondered why your project branch wasn't
getting builds, or couldn't figure out what instance type a worker uses,
this is
I agree -- we faced similar issues in the days when py2.5 - 2.7 were
still available.
I think that if we're clear about the Python version we test on in CI,
and willing to make the effort to fix bugs when we change that (e.g.,
to 3.8), that's sufficient.
Dustin
___
Tom has been involved with taskgraph mechanics in numerous areas,
including release automation, setup of comm-central on Taskcluster,
and the ongoing effort to automate and streamline taskcluster
configuration (roles, hooks, etc.). Just to name a few. His reviews
are reliably detailed, thoughtful
I agree that the fit with moz.build files is awkward. Other issues
(besides those tom raised) include:
- two different methods of reading files can give different results
- the method of combining different `with Files` clauses, even in
different files, is not clear
- *very* deep Python magic u
http://nvm.sh/ seems to be a great way to avoid distro-specific issues
with node/npm installs, and to run exactly the expected version. Mach
could likely use that or do something similar, installing node and npm
in the objdir and using it from there.
Dustin
On Wed, Jan 24, 2018 at 2:08 AM, ISHIK
There will come a point very soon when working on Python 2 code is
about as attractive as working on Perl (sorry, Perl afficionados!).
So this effort will get us to the point where heavily-developed things
run in Python 3, less-heavily-develped stuff is at least "ready to
port" (ensured via variou
I think we should question the assumption that writing
source-code-level documentation is a good activity for newcomers to
the codebase.
Documentation is usually best written by someone with a deep
understanding of what is being documented, not by someone new to the
project. And this documentatio
Since artifact builds came up, I want to make a distinction:
As Axel said, artifact bulids are something that run on laptops and
help us get local test results faster, making a tighter
edit-build-test loop. For automation, we have an optimization process
that can do the same thing, but in a more
This feels like a project that could benefit from a number of people
coordinating a slow hacking-away at it, with the leaf nodes of that
dependency tree being good bite-sized projects suitable for hacking on in
spare cycles or for casual contributors. In my experience with other
projects, one of t
2017-06-02 18:40 GMT-04:00 Ehsan Akhgari :
> On 06/02/2017 06:27 PM, Dustin Mitchell wrote:
>>
>> It could go two ways:
>>
>> 1. "Just try it" again and see what breaks. This runs extra jobs, but
>> has the benefit of finding any accidental bustage adde
of her way and let
> her do her job. :-)
>
> Has this been taken into account?
>
> Thanks,
>
> Ehsan
>
>
>
> On 06/02/2017 04:30 PM, Dustin Mitchell wrote:
>>
>> I wrote up
>>
>> https://docs.google.com/document/d/1kEEUC3ETCIerOxYDoRRZSEFspunJ
I wrote up
https://docs.google.com/document/d/1kEEUC3ETCIerOxYDoRRZSEFspunJgU331CX2wwkFZ_8/edit
It's not a particularly ambitious text, aiming to capture a consensus
rather than propose something new. It's also worth repeating that this
is not a proposal for a big new project, but a design strat
2017-06-01 10:54 GMT-04:00 Andrew Halberstadt :
> Speaking for myself I agree that it seems unlikely we'll be able to both
> reduce machine consumption and increase test coverage, and I think that's
> fine. When I read dustin's proposal, I see:
>
> #1. The interface to try is terrible, we should fi
2017-05-31 9:26 GMT-04:00 Benjamin Smedberg :
> Your ultimate goal is to save $$, and my ultimate goal is to reduce the time
> to results to make the developer cycle faster (let's measure round-trip
> times in minutes instead of hours). I don't believe that running subsets of
> the current jobs wil
I think this topic is big enough already without broadening it into
"how can we make automation better". But getting some data from the
survey sounds great! Maybe it makes sense to get down to the core
question we have here:
When you push to try, how often do you want:
* to run every job relevan
2017-05-26 18:29 GMT-04:00 Mike Hommey :
> Please make it so that it's possible to figure out why some job has run
> or not. Currently, it's near impossible.
Yep. According to my list, that's reason #34 to call the legacy try
parser[*] "trying my patience".
Dustin
[*] reason #13 is that there ar
entation steps as well
> as what a "fuzzyfinder" trychooser might look like:
> https://ahal.ca/blog/2017/fuzzy-try-chooser/
>
> I agree with your 3 variants for try, I just don't think they should be
> implemented under /taskcluster.
>
> On Fri, May 26, 2017 at 2:
Greg sent some previous threads on this topic along, and I've been in
some other related conversations. The topic of optimization overlaps
substantially with try, so I'll mix that in too.
There seems to be a reluctance to talk about this face-to-face, but
there's some urgency in that we're spendi
Thanks Ben --
I agree this is probably not the time to go all-in on this, if it's a
major project. But I think it's a good time to come to some consensus
on direction, so that other changes we make along the way support, or
at least do not preclude, solving it later. In particular, I think
we're
Worth noting that, at least for a while, our desktop-test Docker
images did include a compiler for other purposes, so the
library-dependency risk is already present.
Explicit checks for that seem like the right approach. I believe we
have a few (around glibc symbols, at least) but perhaps not
com
This change will, if luck is with me, be landing today.
Dustin
2016-07-01 17:37 GMT-05:00 Dustin Mitchell :
> Hi folks --
>
> Just to raise awareness that there's a major refactor coming down the
> pike. If you've wrestled with the YAML files in taskcluster/ci/legacy
>
Hi folks --
Just to raise awareness that there's a major refactor coming down the
pike. If you've wrestled with the YAML files in taskcluster/ci/legacy
(nee testing/taskcluster).. I'm sorry. This should fix it. But if
you're currently wrestling with some YAML files, this may bitrot your
changes
Just to chime in on the tasks and task-configuration point: long-term,
I would like for the taskcluster team not to own this. TaskCluster
provides a service, and we are eager for Gecko to use that service and
thus doing a lot of work to set it up and make it awesome. However,
in this case the res
On Tue, Sep 8, 2015 at 12:56 PM, Gregory Szorc wrote:
> I do. I wasn't suggesting we build images at job time: they should
> definitely be pre-built and cached (OK, maybe there is a TaskCluster Graph
> like job that ensures they are built and cached at the very beginning of
> overall job execution
cht wrote:
> On 9/5/15 12:06 AM, Gregory Szorc wrote:
>>
>> First, thank you for spending the time to compose this. It is an
>> excellent write-up. Responses inline.
>>
>> On Fri, Sep 4, 2015 at 1:24 PM, Dustin Mitchell > <mailto:dus...@mozilla.com>> wr
I'd like to get some feedback on changes that we (release engineering
and the taskcluster team) are planning around how we build Firefox. I
apologize that this is a bit long, as I'm trying to include the
necessary background. I have some questions at the end about which
I'd like to have some dis
30 matches
Mail list logo
