802327 - Commit Access (Level 1) for Matt Joras

Status: RESOLVED FIXED

(mozilla.org :: Repository Account Requests, task)

Description

[Matt Joras]

Attachment: id_rsa.pub

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0
Build ID: 20121010150351

Steps to reproduce:

Login: [e-mail]
I've sent in the agreement via signed email.
Benoit Jacob should be able to vouch for me.

Comment 1

[Josh Matthews [:jdm]]

CCing Shannon for form receipt confirmation.

Comment 2

[Benoit Jacob [:bjacob] (mostly away)]

I vouch for Matt because of his work in bug 798033. He needs tryserver access to complete it.

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

Ping!
Is there anything else that needs to be done here before Matt can get access?

Comment 4

[Josh Matthews [:jdm]]

I've pinged Shannon.

Comment 5

[[e-mail]]

I have received the form.

Comment 6

[Josh Matthews [:jdm]]

Go go gadget server-ops!

Comment 7

[Ryan Watson [:w0ts0n]]

Never fear Penny, Inspector Gadget is ALWAYS on duty!

Done!

Comment 8

[Matt Joras]

Thanks! So I should be able to push to the try server now? I might not be doing it right, but I'm getting this when I try to push:
pushing to ssh://hg.mozilla.org/try
remote: Permission denied (publickey,keyboard-interactive).

Comment 9

[Benoit Jacob [:bjacob] (mostly away)]

Well that would mean an issue with your key; make sure that the private key that you're using matches the public key you attached here. Other than that, generic ssh+hg instructions apply.

Also, make sure to set your try options in the commit message of the top changeset in your push. You can use http://trychooser.pub.build.mozilla.org/ . But that's unrelated to the issue you're having here.

Comment 10

[Matt Joras]

Thanks Benoit, I rechecked my configs and I just mistyped my own username *facepalm*.
I think I'm doing the try server messages right, I did this:
hg qref --message "try: -b o -p all -u all -t none"

Comment 11

[Benoit Jacob [:bjacob] (mostly away)]

So you're doing it right, except that we are currently trying to spare tryserver resources as we are running out of capacity. So you should try to set your tryserver options to the minimum that will give you decent coverage for your task. In your case you clearly don't need unit tests, so go for | -u none |. Also, while testing all platforms is nice... there's a compromise to make between that and conserving resources. If you push to try once in a week, it's probably  OK to do -p all. If you push more often than that, you could select two platforms other than your own platform. One of them should be desktop (e.g. win32) the other should be mobile (e.g. android). The above trychooser app allows to find the right keywords easily.

Comment 12

[Benoit Jacob [:bjacob] (mostly away)]

Also, between d and o, I would rather choose d as more often than not, we #include _mode_ things in debug builds than in non-debug ones.

Comment 13

[Matt Joras]

Sounds good to me. What about osx? While I'm digging around in these headers there seems to be a lot of platform specific code. Should I generally do a build for win32 and osx? E.g.
try: -b d -p macosx64,win32,android -u none -t none

Comment 14

[Benoit Jacob [:bjacob] (mostly away)]

OSX and Linux are fairly close in most respect. In general, if you were able to test locally Linux, there's no need to test OSX. Some areas have more platform-specific code though, that's especially the case of gfx/ and widget/. It's up to you and it doesn't make a huge difference to add one more platform to try anyway.