xref: /samba/
Name Date Size

..27-Apr.-20224 KiB

.bzrignoreH A D11-May-20222.3 KiB

.clang-formatH A D20-Jul.-2022701

.editorconfigH A D28-Feb.-2022520

.gitattributesH A D17-Aug.-201835

.github/H05-Dec.-20184 KiB

.gitignoreH A D11-May-20222.3 KiB

.gitlab-ci-coverage-runners.ymlH A D13-Apr.-2021253

.gitlab-ci-coverage.ymlH A D13-Apr.-2021311

.gitlab-ci-default-runners.ymlH A D13-Apr.-20211.9 KiB

.gitlab-ci-default.ymlH A D13-Oct.-2021245

.gitlab-ci-main.ymlH A D26-Jun.-202220.1 KiB

.gitlab-ci-private.ymlH A D13-Apr.-2021133

.gitlab-ci.ymlH A D13-Apr.-202137

.testr.confH A D25-Sep.-2017186

.ycm_extra_conf.pyH A D24-Aug.-20189.9 KiB

auth/H27-Jul.-20224 KiB

bootstrap/H26-Jun.-20224 KiB

buildtools/H01-Apr.-20224 KiB

callcatcher-exceptions.grepH A D25-Sep.-2017149

configureH A D30-Mar.-2022392

configure.developerH A D25-Sep.-201766

COPYINGH A D25-Sep.-201734.3 KiB

coverity/H25-Sep.-20174 KiB

ctdb/H28-Jul.-20224 KiB

dfs_server/H28-Aug.-20204 KiB

docs-xml/H22-Jun.-20224 KiB

dynconfig/H01-Apr.-20214 KiB

examples/H13-Jun.-20204 KiB

file_server/H29-Apr.-20214 KiB

GPG_AA99442FB680B620_replaces_6F33915B6568B7EA.txtH A D08-Mar.-20211 KiB

include/H25-Sep.-20174 KiB

lib/H28-Apr.-20214 KiB

libcli/H07-Aug.-20194 KiB

libds/common/H25-Sep.-20174 KiB

libgpo/H27-Jun.-20224 KiB

librpc/H15-Jul.-20224 KiB

MakefileH A D08-Mar.-20212.8 KiB

nsswitch/H08-Aug.-20224 KiB

packaging/H06-Apr.-20224 KiB

PFIF.txtH A D13-Jun.-2020158

pidl/H20-Mar.-20204 KiB

python/H10-May-20224 KiB

README.cifs-utilsH A D25-Sep.-2017270

README.Coding.mdH A D21-Jul.-202213.6 KiB

README.contributingH A D08-Mar.-20215 KiB

README.mdH A D13-Jun.-20204.8 KiB

release-scripts/H03-Mar.-20224 KiB

script/H10-Jun.-20224 KiB

SECURITY.mdH A D03-Jun.-2020637

selftest/H28-Jul.-20224 KiB

setup.cfgH A D08-Mar.-2021233

source3/HToday4 KiB

source4/H19-Jan.-20224 KiB

testdata/H03-Dec.-20214 KiB

testprogs/H25-Sep.-20174 KiB

tests/H18-Feb.-20224 KiB

testsuite/H12-Mar.-20194 KiB

third_party/H10-Aug.-20224 KiB

VERSIONH A D08-Aug.-20226.1 KiB

VFS-License-clarification.txtH A D08-Mar.-20211.4 KiB

WHATSNEW.txtH A D08-Aug.-20221.5 KiB

wintest/H10-May-20224 KiB

wscriptH A D07-Apr.-202222.8 KiB

wscript_buildH A D21-Jun.-20214.8 KiB

wscript_build_embedded_heimdalH A D22-Jan.-2022113

wscript_build_system_heimdalH A D22-Jan.-2022111

wscript_build_system_mitkrb5H A D22-Jan.-2022100

wscript_configure_embedded_heimdalH A D19-Jan.-2022436

wscript_configure_system_gnutlsH A D28-Jul.-20222.8 KiB

wscript_configure_system_heimdalH A D19-Jan.-20224 KiB

wscript_configure_system_mitkrb5H A D04-Mar.-202214.9 KiB

README.cifs-utils

1As of Sunday March 7th, 2010, the Linux CIFS utilities are no longer
2part of the samba suite of tools and have been split off into their own
3project. Please see this webpage for information on how to acquire and
4build them:
5
6    http://linux-cifs.samba.org/cifs-utils/
7
8

README.Coding.md

1# Coding conventions in the Samba tree
2
3## Quick Start
4
5Coding style guidelines are about reducing the number of unnecessary
6reformatting patches and making things easier for developers to work
7together.
8You don't have to like them or even agree with them, but once put in place
9we all have to abide by them (or vote to change them).  However, coding
10style should never outweigh coding itself and so the guidelines
11described here are hopefully easy enough to follow as they are very
12common and supported by tools and editors.
13
14The basic style for C code is the Linux kernel coding style (See
15Documentation/CodingStyle in the kernel source tree). This closely matches
16what most Samba developers use already anyways, with a few exceptions as
17mentioned below.
18
19The coding style for Python code is documented in
20[PEP8](https://www.python.org/dev/peps/pep-0008/). New Python code
21should be compatible with Python 3.6 onwards.
22
23But to save you the trouble of reading the Linux kernel style guide, here
24are the highlights.
25
26* Maximum Line Width is 80 Characters
27  The reason is not about people with low-res screens but rather sticking
28  to 80 columns prevents you from easily nesting more than one level of
29  if statements or other code blocks.  Use [source3/script/count_80_col.pl](source3/script/count_80_col.pl)
30  to check your changes.
31
32* Use 8 Space Tabs to Indent
33  No whitespace fillers.
34
35* No Trailing Whitespace
36  Use [source3/script/strip_trail_ws.pl](source3/script/strip_trail_ws.pl) to clean up your files before
37  committing.
38
39* Follow the K&R guidelines.  We won't go through all of them here. Do you
40  have a copy of "The C Programming Language" anyways right? You can also use
41  the [format_indent.sh script found in source3/script/](source3/script/format_indent.sh) if all else fails.
42
43
44
45## Editor Hints
46
47### Emacs
48
49Add the follow to your $HOME/.emacs file:
50
51```
52  (add-hook 'c-mode-hook
53	(lambda ()
54		(c-set-style "linux")
55		(c-toggle-auto-state)))
56```
57
58
59### Vi
60
61(Thanks to SATOH Fumiyasu <fumiyas@osstech.jp> for these hints):
62
63For the basic vi editor included with all variants of \*nix, add the
64following to $HOME/.exrc:
65
66```
67  set tabstop=8
68  set shiftwidth=8
69```
70
71For Vim, the following settings in $HOME/.vimrc will also deal with
72displaying trailing whitespace:
73
74```
75  if has("syntax") && (&t_Co > 2 || has("gui_running"))
76	syntax on
77	function! ActivateInvisibleCharIndicator()
78		syntax match TrailingSpace "[ \t]\+$" display containedin=ALL
79		highlight TrailingSpace ctermbg=Red
80	endf
81	autocmd BufNewFile,BufRead * call ActivateInvisibleCharIndicator()
82  endif
83  " Show tabs, trailing whitespace, and continued lines visually
84  set list listchars=tab:����,trail:��,extends:���
85
86  " highlight overly long lines same as TODOs.
87  set textwidth=80
88  autocmd BufNewFile,BufRead *.c,*.h exec 'match Todo /\%>' . &textwidth . 'v.\+/'
89```
90
91### How to use clang-format
92
93Install 'git-format-clang' which is part of the clang suite (Fedora:
94git-clang-format, openSUSE: clang-tools).
95
96Now do your changes and stage them with `git add`. Once they are staged
97format the code using `git clang-format` before you commit.
98
99Now the formatting changed can be viewed with `git diff` against the
100staged changes.
101
102## FAQ & Statement Reference
103
104### Comments
105
106Comments should always use the standard C syntax.  C++
107style comments are not currently allowed.
108
109The lines before a comment should be empty. If the comment directly
110belongs to the following code, there should be no empty line
111after the comment, except if the comment contains a summary
112of multiple following code blocks.
113
114This is good:
115
116```
117	...
118	int i;
119
120	/*
121	 * This is a multi line comment,
122	 * which explains the logical steps we have to do:
123	 *
124	 * 1. We need to set i=5, because...
125	 * 2. We need to call complex_fn1
126	 */
127
128	/* This is a one line comment about i = 5. */
129	i = 5;
130
131	/*
132	 * This is a multi line comment,
133	 * explaining the call to complex_fn1()
134	 */
135	ret = complex_fn1();
136	if (ret != 0) {
137	...
138
139	/**
140	 * @brief This is a doxygen comment.
141	 *
142	 * This is a more detailed explanation of
143	 * this simple function.
144	 *
145	 * @param[in]   param1     The parameter value of the function.
146	 *
147	 * @param[out]  result1    The result value of the function.
148	 *
149	 * @return              0 on success and -1 on error.
150	 */
151	int example(int param1, int *result1);
152```
153
154This is bad:
155
156```
157	...
158	int i;
159	/*
160	 * This is a multi line comment,
161	 * which explains the logical steps we have to do:
162	 *
163	 * 1. We need to set i=5, because...
164	 * 2. We need to call complex_fn1
165	 */
166	/* This is a one line comment about i = 5. */
167	i = 5;
168	/*
169	 * This is a multi line comment,
170	 * explaining the call to complex_fn1()
171	 */
172	ret = complex_fn1();
173	if (ret != 0) {
174	...
175
176	/*This is a one line comment.*/
177
178	/* This is a multi line comment,
179	   with some more words...*/
180
181	/*
182	 * This is a multi line comment,
183	 * with some more words...*/
184```
185
186### Indention & Whitespace & 80 columns
187
188To avoid confusion, indentations have to be tabs with length 8 (not 8
189' ' characters).  When wrapping parameters for function calls,
190align the parameter list with the first parameter on the previous line.
191Use tabs to get as close as possible and then fill in the final 7
192characters or less with whitespace.  For example,
193
194```
195	var1 = foo(arg1, arg2,
196		   arg3);
197```
198
199The previous example is intended to illustrate alignment of function
200parameters across lines and not as encourage for gratuitous line
201splitting.  Never split a line before columns 70 - 79 unless you
202have a really good reason. Be smart about formatting.
203
204One exception to the previous rule is function calls, declarations, and
205definitions. In function calls, declarations, and definitions, either the
206declaration is a one-liner, or each parameter is listed on its own
207line. The rationale is that if there are many parameters, each one
208should be on its own line to make tracking interface changes easier.
209
210
211## If, switch, & Code blocks
212
213Always follow an `if` keyword with a space but don't include additional
214spaces following or preceding the parentheses in the conditional.
215This is good:
216
217```
218	if (x == 1)
219```
220
221This is bad:
222
223```
224	if ( x == 1 )
225```
226
227Yes we have a lot of code that uses the second form and we are trying
228to clean it up without being overly intrusive.
229
230Note that this is a rule about parentheses following keywords and not
231functions.  Don't insert a space between the name and left parentheses when
232invoking functions.
233
234Braces for code blocks used by `for`, `if`, `switch`, `while`, `do..while`, etc.
235should begin on the same line as the statement keyword and end on a line
236of their own. You should always include braces, even if the block only
237contains one statement.  NOTE: Functions are different and the beginning left
238brace should be located in the first column on the next line.
239
240If the beginning statement has to be broken across lines due to length,
241the beginning brace should be on a line of its own.
242
243The exception to the ending rule is when the closing brace is followed by
244another language keyword such as else or the closing while in a `do..while`
245loop.
246
247Good examples:
248
249```
250	if (x == 1) {
251		printf("good\n");
252	}
253
254	for (x=1; x<10; x++) {
255		print("%d\n", x);
256	}
257
258	for (really_really_really_really_long_var_name=0;
259	     really_really_really_really_long_var_name<10;
260	     really_really_really_really_long_var_name++)
261	{
262		print("%d\n", really_really_really_really_long_var_name);
263	}
264
265	do {
266		printf("also good\n");
267	} while (1);
268```
269
270Bad examples:
271
272```
273	while (1)
274	{
275		print("I'm in a loop!\n"); }
276
277	for (x=1;
278	     x<10;
279	     x++)
280	{
281		print("no good\n");
282	}
283
284	if (i < 10)
285		print("I should be in braces.\n");
286```
287
288
289### Goto
290
291While many people have been academically taught that `goto`s are
292fundamentally evil, they can greatly enhance readability and reduce memory
293leaks when used as the single exit point from a function. But in no Samba
294world what so ever is a goto outside of a function or block of code a good
295idea.
296
297Good Examples:
298
299```
300	int function foo(int y)
301	{
302		int *z = NULL;
303		int ret = 0;
304
305		if (y < 10) {
306			z = malloc(sizeof(int) * y);
307			if (z == NULL) {
308				ret = 1;
309				goto done;
310			}
311		}
312
313		print("Allocated %d elements.\n", y);
314
315	 done:
316		if (z != NULL) {
317			free(z);
318		}
319
320		return ret;
321	}
322```
323
324
325### Primitive Data Types
326
327Samba has large amounts of historical code which makes use of data types
328commonly supported by the C99 standard. However, at the time such types
329as boolean and exact width integers did not exist and Samba developers
330were forced to provide their own.  Now that these types are guaranteed to
331be available either as part of the compiler C99 support or from
332lib/replace/, new code should adhere to the following conventions:
333
334  * Booleans are of type `bool` (not `BOOL`)
335  * Boolean values are `true` and `false` (not `True` or `False`)
336  * Exact width integers are of type `[u]int[8|16|32|64]_t`
337
338Most of the time a good name for a boolean variable is 'ok'. Here is an
339example we often use:
340
341```
342	bool ok;
343
344	ok = foo();
345	if (!ok) {
346		/* do something */
347	}
348```
349
350It makes the code more readable and is easy to debug.
351
352### Typedefs
353
354Samba tries to avoid `typedef struct { .. } x_t;` so we do always try to use
355`struct x { .. };`. We know there are still such typedefs in the code,
356but for new code, please don't do that anymore.
357
358### Initialize pointers
359
360All pointer variables MUST be initialized to NULL. History has
361demonstrated that uninitialized pointer variables have lead to various
362bugs and security issues.
363
364Pointers MUST be initialized even if the assignment directly follows
365the declaration, like pointer2 in the example below, because the
366instructions sequence may change over time.
367
368Good Example:
369
370```
371	char *pointer1 = NULL;
372	char *pointer2 = NULL;
373
374	pointer2 = some_func2();
375
376	...
377
378	pointer1 = some_func1();
379```
380
381Bad Example:
382
383```
384	char *pointer1;
385	char *pointer2;
386
387	pointer2 = some_func2();
388
389	...
390
391	pointer1 = some_func1();
392```
393
394### Make use of helper variables
395
396Please try to avoid passing function calls as function parameters
397in new code. This makes the code much easier to read and
398it's also easier to use the "step" command within gdb.
399
400Good Example:
401
402```
403	char *name = NULL;
404	int ret;
405
406	name = get_some_name();
407	if (name == NULL) {
408		...
409	}
410
411	ret = some_function_my_name(name);
412	...
413```
414
415
416Bad Example:
417
418```
419	ret = some_function_my_name(get_some_name());
420	...
421```
422
423Please try to avoid passing function return values to if- or
424while-conditions. The reason for this is better handling of code under a
425debugger.
426
427Good example:
428
429```
430	x = malloc(sizeof(short)*10);
431	if (x == NULL) {
432		fprintf(stderr, "Unable to alloc memory!\n");
433	}
434```
435
436Bad example:
437
438```
439	if ((x = malloc(sizeof(short)*10)) == NULL ) {
440		fprintf(stderr, "Unable to alloc memory!\n");
441	}
442```
443
444There are exceptions to this rule. One example is walking a data structure in
445an iterator style:
446
447```
448	while ((opt = poptGetNextOpt(pc)) != -1) {
449		   ... do something with opt ...
450	}
451```
452
453Another exception: DBG messages for example printing a SID or a GUID:
454Here we don't expect any surprise from the printing functions, and the
455main reason of this guideline is to make debugging easier. That reason
456rarely exists for this particular use case, and we gain some
457efficiency because the DBG_ macros don't evaluate their arguments if
458the debuglevel is not high enough.
459
460```
461	if (!NT_STATUS_IS_OK(status)) {
462		struct dom_sid_buf sid_buf;
463		struct GUID_txt_buf guid_buf;
464		DBG_WARNING(
465		    "objectSID [%s] for GUID [%s] invalid\n",
466		    dom_sid_str_buf(objectsid, &sid_buf),
467		    GUID_buf_string(&cache->entries[idx], &guid_buf));
468	}
469```
470
471But in general, please try to avoid this pattern.
472
473
474### Control-Flow changing macros
475
476Macros like `NT_STATUS_NOT_OK_RETURN` that change control flow
477(`return`/`goto`/etc) from within the macro are considered bad, because
478they look like function calls that never change control flow. Please
479do not use them in new code.
480
481The only exception is the test code that depends repeated use of calls
482like `CHECK_STATUS`, `CHECK_VAL` and others.
483
484
485### Error and out logic
486
487Don't do this:
488
489```
490	frame = talloc_stackframe();
491
492	if (ret == LDB_SUCCESS) {
493		if (result->count == 0) {
494			ret = LDB_ERR_NO_SUCH_OBJECT;
495		} else {
496			struct ldb_message *match =
497				get_best_match(dn, result);
498			if (match == NULL) {
499				TALLOC_FREE(frame);
500				return LDB_ERR_OPERATIONS_ERROR;
501			}
502			*msg = talloc_move(mem_ctx, &match);
503		}
504	}
505
506	TALLOC_FREE(frame);
507	return ret;
508```
509
510It should be:
511
512```
513	frame = talloc_stackframe();
514
515	if (ret != LDB_SUCCESS) {
516		TALLOC_FREE(frame);
517		return ret;
518	}
519
520	if (result->count == 0) {
521		TALLOC_FREE(frame);
522		return LDB_ERR_NO_SUCH_OBJECT;
523	}
524
525	match = get_best_match(dn, result);
526	if (match == NULL) {
527		TALLOC_FREE(frame);
528		return LDB_ERR_OPERATIONS_ERROR;
529	}
530
531	*msg = talloc_move(mem_ctx, &match);
532	TALLOC_FREE(frame);
533	return LDB_SUCCESS;
534```
535
536
537### DEBUG statements
538
539Use these following macros instead of DEBUG:
540
541```
542DBG_ERR         log level 0		error conditions
543DBG_WARNING     log level 1		warning conditions
544DBG_NOTICE      log level 3		normal, but significant, condition
545DBG_INFO        log level 5		informational message
546DBG_DEBUG       log level 10		debug-level message
547```
548
549Example usage:
550
551```
552DBG_ERR("Memory allocation failed\n");
553DBG_DEBUG("Received %d bytes\n", count);
554```
555
556The messages from these macros are automatically prefixed with the
557function name.
558
559
560
561### PRINT format specifiers PRIuxx
562
563Use %PRIu32 instead of %u for uint32_t. Do not assume that this is valid:
564
565/usr/include/inttypes.h
566104:# define PRIu32             "u"
567
568It could be possible to have a platform where "unsigned" is 64-bit. In theory
569even 16-bit. The point is that "unsigned" being 32-bit is nowhere specified.
570The PRIuxx specifiers are standard.
571
572Example usage:
573
574```
575D_DEBUG("Resolving %"PRIu32" SID(s).\n", state->num_sids);
576```
577
578Note:
579
580Do not use PRIu32 for uid_t and gid_t, they do not have to be uint32_t.
581

README.contributing

1How to contribute a patch to Samba
2----------------------------------
3
4Please see https://wiki.samba.org/index.php/Contribute
5for detailed set-by-step instructions on how to submit a patch
6for Samba via GitLab.
7
8Samba's GitLab mirror is at https://gitlab.com/samba-team/samba
9
10Ownership of the contributed code
11---------------------------------
12
13Samba is a project with distributed copyright ownership, which means
14we prefer the copyright on parts of Samba to be held by individuals
15rather than corporations if possible. There are historical legal
16reasons for this, but one of the best ways to explain it is that it's
17much easier to work with individuals who have ownership than corporate
18legal departments if we ever need to make reasonable compromises with
19people using and working with Samba.
20
21We track the ownership of every part of Samba via git, our source code
22control system, so we know the provenance of every piece of code that
23is committed to Samba.
24
25So if possible, if you're doing Samba changes on behalf of a company
26who normally owns all the work you do please get them to assign
27personal copyright ownership of your changes to you as an individual,
28that makes things very easy for us to work with and avoids bringing
29corporate legal departments into the picture.
30
31If you can't do this we can still accept patches from you owned by
32your employer under a standard employment contract with corporate
33copyright ownership. It just requires a simple set-up process first.
34
35We use a process very similar to the way things are done in the Linux
36kernel community, so it should be very easy to get a sign off from
37your corporate legal department. The only changes we've made are to
38accommodate the licenses we use, which are GPLv3 and LGPLv3 (or later)
39whereas the Linux kernel uses GPLv2.
40
41The process is called signing.
42
43How to sign your work
44---------------------
45
46Once you have permission to contribute to Samba from
47your employer, simply email a copy of the following text
48from your corporate email address to contributing@samba.org
49
50------------------------------------------------------------
51Samba Developer's Declaration, Version 1.0
52
53By making a contribution to this project, I certify that:
54
55(a) The contribution was created in whole or in part by me and I
56    have the right to submit it under the appropriate
57    version of the GNU General Public License; or
58
59(b) The contribution is based upon previous work that, to the best
60    of my knowledge, is covered under an appropriate open source
61    license and I have the right under that license to submit that
62    work with modifications, whether created in whole or in part
63    by me, under the GNU General Public License, in the
64    appropriate version; or
65
66(c) The contribution was provided directly to me by some other
67    person who certified (a) or (b) and I have not modified
68    it.
69
70(d) I understand and agree that this project and the
71    contribution are public and that a record of the
72    contribution (including all metadata and personal
73    information I submit with it, including my sign-off) is
74    maintained indefinitely and may be redistributed
75    consistent with the Samba Team's policies and the
76    requirements of the GNU GPL where they are relevant.
77
78(e) I am granting this work to this project under the terms of both
79    the GNU General Public License and the GNU Lesser General Public
80    License as published by the Free Software Foundation; either version
81    3 of these Licenses, or (at the option of the project) any later
82    version.
83
84    http://www.gnu.org/licenses/gpl-3.0.html
85    http://www.gnu.org/licenses/lgpl-3.0.html
86------------------------------------------------------------
87
88We will maintain a copy of that email as a record that you have the
89rights to contribute code to Samba under the required licenses whilst
90working for the company where the email came from.
91
92Then when sending in a patch via the normal mechanisms described
93above, add a line that states:
94
95Signed-off-by: Random J Developer <random@developer.example.org>
96
97using your real name and the email address you sent the original email
98you used to send the Samba Developer's Declaration to us
99(sorry, no pseudonyms or anonymous contributions.)
100
101That's it ! Such code can then quite happily contain changes that have
102copyright messages such as :
103
104        (C) Example Corporation.
105
106and can be merged into the Samba codebase in the same way as patches
107from any other individual. You don't need to send in a copy of the
108Samba Developer's Declaration for each patch, or inside each
109patch. Just the sign-off message is all that is required once we've
110received the initial email.
111
112Have fun and happy Samba hacking !
113
114The Samba Team.
115
116
117The "Samba Developer's Declaration, Version 1.0" is:
118  (C) 2011 Software Freedom Conservancy, Inc.
119  (C) 2005 Open Source Development Labs, Inc.
120
121licensed under Creative Commons Attribution-ShareAlike 4.0 License as found
122at https://creativecommons.org/licenses/by-sa/4.0/legalcode and based on
123"Developer's Certificate of Origin 1.1" as found at
124http://web.archive.org/web/20070306195036/http://osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html
125

README.md

1About Samba
2===========
3
4Samba is the standard Windows interoperability suite of
5programs for Linux and Unix.
6Samba is Free Software licensed under the GNU General Public License and
7the Samba project is a member of the Software Freedom Conservancy.
8Since 1992, Samba has provided secure, stable and fast file and print services
9for all clients using the SMB/CIFS protocol, such as all versions of DOS
10and Windows, OS/2, Linux and many others.
11Samba is an important component to seamlessly integrate Linux/Unix Servers and
12Desktops into Active Directory environments. It can function both as a
13domain controller or as a regular domain member.
14
15
16For the AD DC implementation a full HOWTO is provided at:
17      https://wiki.samba.org/index.php/Samba4/HOWTO
18
19Community guidelines can be read at:
20      https://wiki.samba.org/index.php/How_to_do_Samba:_Nicely
21
22This software is freely distributable under the GNU public license, a
23copy of which you should have received with this software (in a file
24called COPYING).
25
26
27
28CONTRIBUTIONS
29=============
30
31Please see https://wiki.samba.org/index.php/Contribute
32for detailed set-by-step instructions on how to submit a patch
33for Samba via GitLab.
34
35Samba's GitLab mirror is at https://gitlab.com/samba-team/samba
36
37OUR CONTRIBUTORS
38================
39
40See https://www.samba.org/samba/team/ for details of the Samba Team,
41as well as details of all those currently active in Samba development.
42
43If you like a particular feature then look through the git change-log
44(on the web at https://gitweb.samba.org/?p=samba.git;a=summary) and see
45who added it, then send them an email.
46
47Remember that free software of this kind lives or dies by the response
48we get. If no one tells us they like it then we'll probably move onto
49something else.
50
51
52MORE INFO
53=========
54
55DOCUMENTATION
56-------------
57
58There is quite a bit of documentation included with the package,
59including man pages and the wiki at https://wiki.samba.org
60
61If you would like to help with our documentation, please contribute
62that improved content to the wiki, we are moving as much content there
63as possible.
64
65
66MAILING LIST
67------------
68
69Please do NOT send subscription/unsubscription requests to the lists!
70
71There is a mailing list for discussion of Samba.  For details go to
72<https://lists.samba.org/> or send mail to <samba-subscribe@lists.samba.org>
73
74There is also an announcement mailing list where new versions are
75announced.  To subscribe go to <https://lists.samba.org/> or send mail
76to <samba-announce-subscribe@lists.samba.org>.  All announcements also
77go to the samba list, so you only need to be on one.
78
79For details of other Samba mailing lists and for access to archives, see
80<https://lists.samba.org/>
81
82
83MAILING LIST ETIQUETTE
84----------------------
85
86A few tips when submitting to this or any mailing list.
87
881. Make your subject short and descriptive. Avoid the words "help" or
89   "Samba" in the subject. The readers of this list already know that
90   a) you need help, and b) you are writing about samba (of course,
91   you may need to distinguish between Samba PDC and other file
92   sharing software). Avoid phrases such as "what is" and "how do
93   i". Some good subject lines might look like "Slow response with
94   Excel files" or "Migrating from Samba PDC to NT PDC".
95
962. If you include the original message in your reply, trim it so that
97   only the relevant lines, enough to establish context, are
98   included. Chances are (since this is a mailing list) we've already
99   read the original message.
100
1013. Trim irrelevant headers from the original message in your
102   reply. All we need to see is a) From, b) Date, and c) Subject. We
103   don't even really need the Subject, if you haven't changed
104   it. Better yet is to just preface the original message with "On
105   [date] [someone] wrote:".
106
1074. Please don't reply to or argue about spam, spam filters or viruses
108   on any Samba lists. We do have a spam filtering system that is
109   working quite well thank you very much but occasionally unwanted
110   messages slip through. Deal with it.
111
1125. Never say "Me too." It doesn't help anyone solve the
113   problem. Instead, if you ARE having the same problem, give more
114   information. Have you seen something that the other writer hasn't
115   mentioned, which may be helpful?
116
1176. If you ask about a problem, then come up with the solution on your
118   own or through another source, by all means post it. Someone else
119   may have the same problem and is waiting for an answer, but never
120   hears of it.
121
1227. Give as much *relevant* information as possible such as Samba
123   release number, OS, kernel version, etc...
124
1258. RTFM. Google.
126
127
128WEBSITE
129-------
130
131A Samba website has been setup with lots of useful info. Connect to:
132
133https://www.samba.org/
134
135As well as general information and documentation, this also has searchable
136archives of the mailing list and links to other useful resources such as
137the wiki.
138