There are many reasons why trying to handle malloc() returning NULL by
any other way than calling abort() is not beneficial:
- Usually malloc() does not return NULL, thanks to memory overcommit.
Instead, the program gets SIGSEGV signal when it tries to access the
memory.
- Trying to handle NULL will create failure paths that are impractical
to test. There is no way to be sure the compositor still works once
such path is actually taken.
- Those failure path will clutter the code, increasing maintenance and
development burden.
- Sometimes there just isn't a good way to handle the failure.
For more discussion, see the issue link below.
Closes: https://gitlab.freedesktop.org/wayland/weston/-/issues/631
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This was prompted by a recent discussion on #dri-devel IRC channel,
where the use of pseudonyms to maintain anonymity was said to be a
normal and accepted practice. See:
https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=dri-devel&highlight_names=&date=2021-02-09
and look for the discussion around pq and Lyude.
Until then, I was hesitant to accept Signed-off-by's with names that
looked very much not a real name.
Clarify our documentation that pseudonyms are ok.
Note, that is not what the Linux kernel documentation says today in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst
which says that pseudonyms are not ok. According to the discussion, this
should probably be fixed in the kernel too.
Since we are now ok with pseudonyms in Signed-off-by, there is no reason
left to accept any patches without a Signed-off-by. This clarifies our
policy and takes the burden of case-by-case consideration away from
maintainers.
The wording about needing to use a personal email address is my
addition. The intention is to ensure a globally unique handle for a
person while that person remains anonymous, so that the Signed-off-by
cannot be mistaken for someone elses.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We haven't received any emailed patches in years I think, and they would
be inconvenient to process. Make it clear that emailed patches are
unwanted.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The DCO was fetched from https://developercertificate.org/ on Feb 4, 2019.
DCO-1.1.txt is a verbatim copy of it.
We should carry a copy of this legal document to be explicit on what wording we
refer to. A link to the URL is not enough, because it may go stale or change
contents without notice.
This clarifies on what the S-o-b actually means. The meaning itself is the same
as before.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Found while being parsed by doxygen (when used recursively), this fixes
the markdown bits as to be displayed properly.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
* Cover letters are no more; presumably the changes since the previous
revision should be summarised in the MR
* Code should be indented with tabs, not implemented with tabs
Signed-off-by: Will Thompson <will@willthompson.co.uk>
Though Wayland and the protocols still use mail-based patch review,
Weston can now move to GitLab MRs with review through that system.
Add some documentation on how to submit patches through GitLab,
specifically targeted at people who may be familiar with GitLab review,
but not familiar with our rebasing microcommit workflow.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Change some Wayland-specific references to instead refer to Weston.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Taken from Pekka's wayland/wayland@630c25f4c1 and follow-ups, use
Wayland's CONTRIBUTING document as a basis for Weston.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
