From 866e3204cee593817850f5e5c23a0bcf7af9c591 Mon Sep 17 00:00:00 2001 From: Stef Walter Date: Tue, 5 Feb 2013 11:50:16 +0100 Subject: Add documentation about contributing to p11-kit --- HACKING | 34 ++++++++-------------------------- 1 file changed, 8 insertions(+), 26 deletions(-) (limited to 'HACKING') diff --git a/HACKING b/HACKING index 63454f8..5fa9570 100644 --- a/HACKING +++ b/HACKING @@ -1,31 +1,13 @@ HACKING p11-kit - * Website: http://p11-glue.freedesktop.org/p11-kit.html + * Documentation on developing p11-kit: + http://p11-glue.freedesktop.org/doc/p11-kit/devel.html - * Mailing list: p11-glue@lists.freedesktop.org + * General Website: + http://p11-glue.freedesktop.org/p11-kit.html - * Bugs: https://bugs.freedesktop.org/enter_bug.cgi?product=p11-glue + * Mailing list: + p11-glue@lists.freedesktop.org -PRECONDITIONS and UNEXPECTED SYSTEM ISSUES - -We don't try to guarantee completely robust and problem free behavior in cases -where the caller or process isn't behaving. We consider these to be outside of -our control: - - * Broken input from callers. We use preconditions to check input - and immediately return. - - * Out of memory. It is pretty much impossible to handle out of memory - errors correctly. Handling them alongside other errors is naive and - broken. - - We do check the results from all memory allocations. - - As a nod to the behavior of callers of this library, we don't abort on - memory allocation failures. We use preconditions with somewhat sane results. - - We don't try to guarantee library state (such as locks or memory leaks) - when memory allocation fails. - - Exception: when reading files or allocating potentially unbounded amounts - of memory, we should respond robustly to memory allocation failures. + * Report bugs here: + https://bugs.freedesktop.org/enter_bug.cgi?product=p11-glue -- cgit v1.1