mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla gemeenschap

Patrick Cloke: Mentoring and Time

Mozilla planet - wo, 09/07/2014 - 23:32

No, this is not about being late places, it’s about respecting people’s time. I won’t go deep into why this is important as, Michael Haggerty wrote an awesome article on this. His thoughts boiled down to a single line of advice:

DON’T WASTE OTHER PEOPLE’S TIME

I think this applies to any type of mentoring, and not only open source work, but any formal or informal mentoring! This advice isn’t meant just for GSoC students, for interns or new employees, but also things I’d like to remind myself to do when someone is helping me.

To make this sound positive, I’d reword the above advice as:

Respect other people’s time!

Someone is willing to help you, so assume some good faith, but help them help you! Some actions to focus on:

  • Ask focused questions! If you do not understand an answer, do not re-ask the same question, but ask followup question. Show you’ve researched the original answer and attempted to understand it. Write sample code, play with it, etc. If you think the answer given doesn’t apply to your question, reword your question: your mentor probably did not understand.
  • Be cognizant of timezones: if you’d like a question answered (in realtime), ask it when the person is awake! (And this includes realizing if they have just woken up or are going to bed.)
  • Your mentor may not have the context you do: they might be helping many people at once, or even working on something totally different than you! Try not to get frustrated if you have to explain your context to them multiple times or have to clarify your question. You are living and breathing the code you’re working in; they are not.
  • Don’t be afraid to share code. It’s much easier to ask a question when there’s a specific example in front of you. Be specific and don’t talk theoretically.
  • Don’t be upset if you’re asked to change code (e.g. receive an r-)! Part of helping you to grow is telling you what you’re doing wrong.
  • Working remotely is hard. It requires effort to build a level of trust between people. Don’t just assume it will come in time, but work at it and try to get to know and understand your mentor.
  • Quickly respond to both feedback and questions. Your mentor is taking their precious time to help you. If they ask you a question or ask something of you, do it ASAP. If you can’t answer their question immediately, at least let them know you received it and will soon look at it.
  • If there are multiple people helping you, assume that they communicate (without your knowledge). Don’t…
    • …try to get each of them to do separate parts of a project for you.
    • …ask the same question to multiple people hoping for different answers.

The above is a lot to consider. I know that I have a tendency to do some of the above. Using your mentors time efficiently will not only make your mentor happy, but it will probably cause them to want to give you more of their time.

Mentoring is also hard and a skill to practice. Although I’ve talked a lot about what a mentee needs to do, it is also important that a mentor makes h(im|er)self available and open. A few thoughts on interacting as a mentor:

  • Be cognizant of culture and language (as in, the level at which a mentor and mentee share a common language). In particular, colloquialisms should be avoided whenever possible. At least until a level of trust is reached.
  • Be tactful when giving feedback. Thank people for submitting a patch, give good, actionable feedback quickly. Concentrate more on overall code design and algorithms than nits. (Maybe even point out nits, but fix them yourself for an initial patch.)
Categorieën: Mozilla-nl planet

Byron Jones: using “bugmail filtering” to exclude notifications you don’t want

Mozilla planet - wo, 09/07/2014 - 18:39

a common problem with bugzilla emails (aka bugmail) is there’s too much of it.  if you are involved in a bug or watching a component you receive all changes made to bugs, even those you have no interest in receiving.

earlier this week we pushed a new feature to bugzilla.mozilla.org : bugmail filtering.

bugmail_filtering

this feature is available on the “bugmail filtering” tab on the “user preference” page.

 

there are many reasons why bugzilla may send you notification of a change to a bug:

  • you reported the bug
  • the bug is assigned to you
  • you are the qa-contact for the bug
  • you are on the cc list
  • you are watching the bug’s product/component
  • you are watching another user who received notification of the bug
  • you are a “global watcher”

dealing with all that bugmail can be time consuming.  one way address this issue is to use the x-headers present in every bugmail to categorise and separate bugmail into different folders in your inbox.  unfortunately this option isn’t available to everyone (eg. gmail users still cannot filter on any email header).

bugmail filtering allows you to tell bugzilla to notify you only if it’s a change that you’re interested in.

for example, you can say:

don’t send me an email when the qa-whiteboard field is changed unless the bug is assigned to me

  filter-qa

if multiple filters are applicable to the same bug change, include filters override exclude filters.  this interplay allows you to write filters to express “don’t send me an email unless …”

don’t send me an email for developer tools bugs that i’m CC’ed on unless the bug’s status is changed

  • first, exclude all developer tools emails:

filter-devtools-exclude

  • then override the exclusion with an inclusion for just the status changes:

filter-devtools-include


Filed under: bmo
Categorieën: Mozilla-nl planet

Pete Moore: Weekly review 2014-07-09

Mozilla planet - wo, 09/07/2014 - 16:31

This week I am on build duty.

At the tail end of last week, I managed to finish of l10n patches and sent them over to Aki to get them reviewed. He has now reviewed them, and the next step is to process his review comments.

Other than this, I raised a bug about refactoring the beagle config and created a patch, and am currently in discussions with Aki about it.

I’m still processing the loaners for Joel Maher (thanks Coop for taking care of the windows loaners) - I hit some problems on the way setting up vnc on Mountain Lion - working through this currently (also involved Armen to get his expertise).

After the loaners are done, I also have my own queue of optimisations that I’d like to look at that are related to build duty (open bugs).

Categorieën: Mozilla-nl planet

Niko Matsakis: An experimental new type inference scheme for Rust

Mozilla planet - wo, 09/07/2014 - 16:08

While on vacation, I’ve been working on an alternate type inference scheme for rustc. (Actually, I got it 99% working on the plane, and have been slowly poking at it ever since.) This scheme simplifies the code of the type inferencer dramatically and (I think) helps to meet our intutions (as I will explain). It is however somewhat less flexible than the existing inference scheme, though all of rustc and all the libraries compile without any changes. The scheme will (I believe) make it much simpler to implement to proper one-way matching for traits (explained later).

Note: Changing the type inference scheme doesn’t really mean much to end users. Roughly the same set of Rust code still compiles. So this post is really mostly of interest to rustc implementors.

The new scheme in a nutshell

The new scheme is fairly simple. It is based on the observation that most subtyping in Rust arises from lifetimes (though the scheme is extensible to other possible kinds of subtyping, e.g. virtual structs). It abandons unification and the H-M infrastructure and takes a different approach: when a type variable V is first related to some type T, we don’t set the value of V to T directly. Instead, we say that V is equal to some type U where U is derived by replacing all lifetimes in T with lifetime variables. We then relate T and U appropriately.

Let me give an example. Here are two variables whose type must be inferred:

'a: { // 'a --> name of block's lifetime let x = 3; let y = &x; ... }

Let’s say that the type of x is $X and the type of y is $Y, where $X and $Y are both inference variables. In that case, the first assignment generates the constraint that int <: $X and the second generates the constraint that &'a $X <: $Y. To resolve the first constraint, we would set $X directly to int. This is because there are no lifetimes in the type int. To resolve the second constraint, we would set $Y to &'0 int – here '0 represents a fresh lifetime variable. We would then say that &'a int <: &'0 int, which in turn implies that '0 <= 'a. After lifetime inference is complete, the types of x and y would be int and &'a int as expected.

Without unification, you might wonder what happens when two type variables are related that have not yet been associated with any concrete type. This is actually somewhat challenging to engineer, but it certainly does happen. For example, there might be some code like:

let mut x; // type: $X let mut y = None; // type: Option<$0> loop { if y.is_some() { x = y.unwrap(); ... } ... }

Here, at the point where we process x = y.unwrap(), we do not yet know the values of either $X or $0. We can say that the type of y.unwrap() will be $0 but we must now process the constrint that $0 <: $X. We do this by simply keeping a list of outstanding constraints. So neither $0 nor $X would (yet) be assigned a specific type, but we’d remember that they were related. Then, later, when either $0 or $X is set to some specific type T, we can go ahead and instantiate the other with U, where U is again derived from T by replacing all lifetimes with lifetime variables. Then we can relate T and U appropriately.

If we wanted to extend the scheme to handle more kinds of inference beyond lifetimes, it can be done by adding new kinds of inference variables. For example, if we wanted to support subtyping between structs, we might add struct variables.

What advantages does this scheme have to offer?

The primary advantage of this scheme is that it is easier to think about for us compiler engineers. Every type variable is either set – in which case its type is known precisely – or unset – in which case its type is not known at all. In the current scheme, we track a lower- and upper-bound over time. This makes it hard to know just how much is really known about a type. Certainly I know that when I think about inference I still think of the state of a variable as a binary thing, even though I know that really it’s something which evolves.

What prompted me to consider this redesign was the need to support one-way matching as part of trait resolution. One-way matching is basically a way of saying: is there any substitution S such that T <: S(U) (whereas normal matching searches for a substitution applied to both sides, like S(T) <: S(U)).

One-way matching is very complicated to support in the current inference scheme: after all, if there are type variables that appear in T or U which are partially constrained, we only know bounds on their eventual type. In practice, these bounds actually tell us a lot: for example, if a type variable has a lower bound of int, it actually tells us that the type variable is int, since in Rust’s type system there are no super- of sub-types of int. However, encoding this sort of knowledge is rather complex – and ultimately amounts to precisely the same thing as this new inference scheme.

Another advantage is that there are various places in the Rust’s type checker whether we query the current state of a type variable and make decisions as a result. For example, when processing *x, if the type of x is a type variable T, we would want to know the current state of T – is T known to be something inherent derefable (like &U or &mut U) or a struct that must implement the Deref trait? The current APIs for doing this bother me because they expose the bounds of U – but those bounds can change over time. This seems “risky” to me, since it’s only sound for us to examine those bounds if we either (a) freeze the type of T or (b) are certain that we examine properties of the bound that will not change. This problem does not exist in the new inference scheme: anything that might change over time is abstracted into a new inference variable of its own.

What are the disadvantages?

One form of subtyping that exists in Rust is not amenable to this inference. It has to do with universal quantification and function types. Function types that are “more polymorphic” can be subtypes of functions that are “less polymorphic”. For example, if I have a function type like <'a> fn(&'a T) -> &'a uint, this indicates a function that takes a reference to T with any lifetime 'a and returns a reference to a uint with that same lifetime. This is a subtype of the function type fn(&'b T) -> &'b uint. While these two function types look similar, they are quite different: the former accepts a reference with any lifetime but the latter accepts only a reference with the specific lifetime 'b.

What this means is that today if you have a variable that is assigned many times from functions with varying amounts of polymorphism, we will generally infer its type correctly:

fn example<'b>(..) { let foo: <'a> |&'a T| -> &'a int = ...; let bar: |&'b T| -> &'b int = ...; let mut v; v = foo; v = bar; // type of v is inferred to be |&'b T| -> &'b int }

However, this will not work in the newer scheme. Type ascription of some form would be required. As you can imagine, this is not a very .common problem, and it did not arise in any existing code.

(I believe that there are situations which the newer scheme infers correct types and the older scheme will fail to compile; however, I was unable to come up with a good example.)

How does it perform?

I haven’t done extensive measurements. The newer scheme creates a lot of region variables. It seems to perform roughly the same as the older scheme, perhaps a bit slower – optimizing region inference may be able to help.

Categorieën: Mozilla-nl planet

Doug Belshaw: Why Mozilla cares about Web Literacy [whitepaper]

Mozilla planet - wo, 09/07/2014 - 15:41

One of my responsibilities as Web Literacy Lead at Mozilla is to provide some kind of theoretical/conceptual underpinning for why we do what we do. Since the start of the year, along with Karen Smith and some members of the community, I’ve been working on a Whitepaper entitled Why Mozilla cares about Web Literacy.

Webmaker whitepaper

The thing that took time wasn’t really the writing of it – Karen (a post-doc researcher) and I are used to knocking out words quickly – but the re-scoping and design of it. The latter is extremely important as this will serve as a template for future whitepapers. We were heavily influenced by P2PU’s reports around assessment, but used our own Makerstrap styling. I’d like to thank FuzzyFox for all his work around this!

Thanks also to all those colleagues and community members who gave feedback on earlier drafts of the whitepaper. It’s available under a Creative Commons Attribution 4.0 International license and you can fork/improve the template via the GitHub repository. We’re planning for the next whitepaper to be around learning pathways. Once that’s published, we’ll ensure there’s a friendlier way to access them - perhaps via a subdomain of webmaker.org.

Questions? Comments? I’m @dajbelshaw and you can email me at doug@mozillafoundation.org.

Categorieën: Mozilla-nl planet

Gervase Markham: The Latest Airport Security Theatre

Mozilla planet - wo, 09/07/2014 - 15:23

All passengers flying into or out of the UK are being advised to ensure electronic and electrical devices in hand luggage are sufficiently charged to be switched on.

All electronic devices? Including phones, right? So you must be concerned that something dangerous could be concealed inside a package the size of a phone. And including laptops, right? Which are more than big enough to contain said dangerous phone-sized electronics package in the CD drive bay, or the PCMCIA slot, and still work perfectly. Or, the evilness could even be occupying 90% of the body of the laptop, while the other 10% is taken up by an actual phone wired to the display and the power button which shows a pretty picture when the laptop is “switched on”.

Or are the security people going to make us all run 3 applications of their choice and take a selfie using the onboard camera to demonstrate that the device is actually fully working, and not just showing a static image?

I can’t see this as being difficult to engineer around. And meanwhile, it will cause even more problems trying to find charging points in airports. Particularly for people who are transferring from one long flight to another.

Categorieën: Mozilla-nl planet

Rumbling Edge - Thunderbird: 2014-07-08 Calendar builds

Thunderbird - wo, 09/07/2014 - 09:21

Common (excluding Website bugs)-specific: (2)

  • Fixed: 782670 – Allow to save items to calendar, even though they are invitations (override REQUEST with PUBLISH)
  • Fixed: 1026382 – TB 31 beta 1 – Scrollbar partially hidden behind Lightnings Todays pane

Sunbird will no longer be actively developed by the Calendar team.

Windows builds Official Windows

Linux builds Official Linux (i686), Official Linux (x86_64)

Mac builds Official Mac

Categorieën: Mozilla-nl planet

Rumbling Edge - Thunderbird: 2014-07-08 Thunderbird comm-central builds

Thunderbird - wo, 09/07/2014 - 09:20

Thunderbird-specific: (14)

  • Fixed: 788137 – Nick for XMPP chatrooms becomes ‘null’
  • Fixed: 827048 – Filtered messages lost (POP) going to imap or maildir folder (with mail.serverDefaultStoreContractID = @mozilla.org/msgstore/maildirstore;1)
  • Fixed: 920118 – Make “visited link” coloring work in thunderbird (enable and use Places for history)
  • Fixed: 942005 – [meta] Attempt to more closely mimic the new Australis Fx theme.
  • Fixed: 1008822 – Forwarding RSS post as inline does not use default account identity
  • Fixed: 1010140 – libffi dep builds fail to build for comm-central due to “IndexError: string index out of range” pymake error
  • Fixed: 1011616 – Join Chat dialog box won’t close with Auto-join this Chat Room checked
  • Fixed: 1022222 – Free space in account central different under email and accounts
  • Fixed: 1022340 – Port bug 885139 – LWT header image applied to the selected tab isn’t updated upon re-cropping
  • Fixed: 1025373 – TypeError: gCurrentFilterList is undefined when opening filter list with no selected folder
  • Fixed: 1025486 – No tab overflow arrows shown on overflow
  • Fixed: 1026629 – Non-existent priority level PRIORITY_MEDIUM_HIGH requested for notification
  • Fixed: 1030019 – Port |Bug 598615 – HAVE_64BIT_OS changed to HAVE_64BIT_BUILD| to Thunderbird
  • Fixed: 1033568 – TEST-UNEXPECTED-FAIL | /builds/slave/test/build/mozmill/message-header/test-header-toolbar.js | test-header-toolbar.js::test_customize_header_toolbar_reorder_buttons

MailNews Core-specific: (17)

  • Fixed: 1017939 – newly created maildir subfolders folders are created under INBOX instead of INBOX.sbd
  • Fixed: 1018300 – Modify test_pop3MoveFilter.js to use Promises.
  • Fixed: 1018543 – Modify test_pop3FilterActions.js to use Promises
  • Fixed: 1018589 – Can’t add RSS feed with Cyrillic URL -> support idn urls for feeds
  • Fixed: 1022723 – Some headers are sent prefixed with “********:” when they were folded due to their length
  • Fixed: 1023700 – Modify test_pop3MoveFilter2.js to use Promises.
  • Fixed: 1027241 – Import nsICMS* from Gecko to MailNews Core to fix bustage caused by their removal from Gecko
  • Fixed: 1028217 – Update CollectReports() to fix c-c bustage caused by Bug 1010064
  • Fixed: 1028548 – Fix nsMsgMaildirStore::RenameFolder() and make test_nsIMsgLocalMailFolder.js pass with maildir mailbox storage format
  • Fixed: 1028997 – Assertion failure in nsMsgAttachmentHandler.h
  • Fixed: 1030116 – Fix test_pop3MoveFilter2.js to work with maildir.
  • Fixed: 1030291 – Fix test_pop3FilterActions.js to work with maildir.
  • Fixed: 1031291 – Prepare comm-central to m-c changes from bug 762358
  • Fixed: 1031703 – Fix test_msgIDParsing.js to work with maildir.
  • Fixed: 1035086 – Enable MOZ_PSEUDO_DERECURSE on c-c builds
  • Fixed: 1035096 – Avoid much mess by not letting mozilla subconfigure read mozconfig
  • Fixed: 1035590 – Don’t share python virtualenv between c-c and m-c.

Windows builds Official Windows, Official Windows installer

Linux builds Official Linux (i686), Official Linux (x86_64)

Mac builds Official Mac

Categorieën: Mozilla-nl planet

Pagina's