http://docs.travis-ci.com/user/notifications/
> By default, email notifications will be sent to the committer and the commit author, if they are members of the repository (that is, they have push or admin permissions for public repositories, or if they have pull, push or admin permissions for private repositories).
>
> And it will by default send emails when, on the given branch:
>
> * a build was just broken or still is broken
> * a previously broken build was just fixed
http://docs.travis-ci.com/user/notifications/
> By default, email notifications will be sent to the committer and the commit author, if they are members of the repository (that is, they have push or admin permissions for public repositories, or if they have pull, push or admin permissions for private repositories).
>
> And it will by default send emails when, on the given branch:
>
> * a build was just broken or still is broken
> * a previously broken build was just fixed
This code tried to prevent buffer requests from parts of layers that
were occluded by other layers. This doesn't really make sense when
layers can potentially be semi-opaque, and also seems to have not been
totally functional.
Use a new LayerProperties struct to hold all the data necessary to
create or update compositor layers. This reduces a lot of duplication
when passing it along.
Instead of creating, sizing, and setting up layers using several
messages use only one. If the layer already exists, it will be updated
to reflect the new properties. The clip rect is still set in a separate
message, but that will be eliminated in a later commit.
The crate provides an interface to the Mac-specific `task_info()`
function in general, and the module provides an interface to the
TASK_BASIC_INFO flavor. Currently only the `virtual_size` and
`resident_size` values of the `task_basic_info` struct are exposed, but
there's obvious room for expansion.
This is used to implement the -m measurements on Mac.
This idiom has been dying out in new Rust code; it's especially
confusing for layers because there is a higher chance of making the
mistaken assumption that the iteration is occurring over multiple
layers.
Rename find_child_with_layer_and_pipeline_id to
find_child_with_pipeline_and_layer_id so that it matches both the
logical and actual parameter ordering.
Using {:?} prints a debugging representation such as
collections::string::String{
vec: collections::vec::Vec<u8>{
len: 4u,
cap: 4u,
ptr: (0x7f75670285d8 as *mut ())
}
}
which is not very helpful.
