4 @settitle SXEmacs Policies & Procedures Manual
9 @c Define a macro or 2 (abbrevs)
19 Copyright @copyright{} 2004 - 2011 @sy{}
23 @email{steve@@sxemacs.org, @sy{}}
36 @set UPDATED November 6, 2010
38 @c Things would be a lot easier if everything supported the `@copying'
39 @c command, I wouldn't have to put in these conditionals. --SY.
42 This is the SXEmacs Policies & Procedures Manual.
43 It was last updated @value{UPDATED}.
48 Permission is granted to copy, distribute and/or modify this document
49 under the terms of the GNU General Public Licence, Version 2.
51 Permission is granted to copy and distribute translations of this manual
52 into another language, under the above conditions for modified versions.
56 Permission is granted to process this file through Tex and print the
57 results, provided the printed document carries copying permission
58 notice identical to this one except for the removal of this paragraph
59 (this paragraph not being relevant to the printed manual).
64 @dircategory SXEmacs Development
66 * SPPM:: SXEmacs Policies & Procedures Manual.
70 @title SXEmacs Policies & Procedures Manual
71 @subtitle @value{EDITION} edition, last updated on @value{UPDATED}.
72 @vskip 0pt plus 1filll
77 This is the SXEmacs Policies & Procedures Manual.
78 It was last updated @value{UPDATED}.
83 Permission is granted to copy, distribute and/or modify this document
84 under the terms of the GNU General Public Licence, Version 2.
86 Permission is granted to copy and distribute translations of this manual
87 into another language, under the above conditions for modified versions.
91 Permission is granted to process this file through Tex and print the
92 results, provided the printed document carries copying permission
93 notice identical to this one except for the removal of this paragraph
94 (this paragraph not being relevant to the printed manual).
99 @c Set up the headers and footers for the printed output (postscript).
101 @everyheading @thischapter @|@| @thispage
102 @everyfooting @thistitle @|@| @syc{}
106 @node Top, Mission Statement, (dir), (dir)
109 This is the @value{EDITION} edition of the @cite{SXEmacs Policies & Procedures Manual}
116 This document, as its name implies, is directed towards anyone who is
117 actively involved (or thinking of becoming actively involved) in the
118 development of @uref{http://www.sxemacs.org/, SXEmacs}.
121 * Mission Statement:: Why we do what we do
122 * Online Presence:: Where we make our first impressions
123 * Dispute Resolution:: Arguments can be resolved
124 * Coding Style:: Making sure your code looks like our code
125 * Patches:: Handling contributed code/docs
126 * Feature Requests:: Dealing with feature requests
127 * Support Requests:: Handling support requests
128 * Bug Reports:: Dealing with bug reports
129 * Making Releases:: Getting the finished product to the user
130 * New Features:: Getting new stuff into the code base
131 * Compatibility:: With XEmacs and GNU/Emacs
132 * Copyright and Licencing:: We won't accept just any old licence
133 * Developer Recruitment:: How to get new blood
134 * Making/Altering Policies:: Changing or updating this document
135 * Version Control:: How we keep track of the source
136 * Concept Index:: Concept Index
139 @node Mission Statement, Online Presence, Top, Top
140 @chapter SXEmacs Mission Statement
141 @cindex mission statement
145 Our mission is to@dots{}
148 To provide the Open Source community with a text editing and development
149 environment that is based on XEmacs and is 2nd to none in regards to
150 stability, features, and innovation.
152 To foster a user and developer friendly project environment.
154 And, above all, to have fun doing it.
157 @node Online Presence, Dispute Resolution, Mission Statement, Top
158 @comment node-name, next, previous, up
159 @chapter SXEmacs' Online Presence
165 @cindex sxemacs online
166 @cindex online, sxemacs
168 The SXEmacs project maintains a number of @dfn{online} services.
173 @uref{http://www.sxemacs.org/, The SXEmacs Web Site}
175 @uref{http://downloads.sxemacs.org/, Release and Snapshot Tarballs}
177 @uref{irc://irc.freenode.net/#sxemacs, The SXEmacs IRC channel}
179 @uref{http://issues.sxemacs.org/, The SXEmacs Issue Tracker} @ref{Bug Reports}
180 @ref{Feature Requests} @ref{Support Requests}.
182 @uref{http://store.sxemacs.org/, SXEmacs Merchandise}
186 * Web Site:: Our shop front
187 * Download Site:: Where we keep the tarballs
188 * IRC:: For those who like to talk about it
189 * Merchandise:: Got the software@dots{} Get the T-Shirt
192 @node Web Site, Download Site, Online Presence, Online Presence
193 @comment node-name, next, previous, up
194 @chapter SXEmacs Web Site
197 @cindex www.sxemacs.org
199 The SXEmacs web site content is kept under the same version control
200 system as SXEmacs itself @ref{Version Control}. That means that
201 anyone can submit changes and updates to the site in the same manner
202 that they would for code submissions to SXEmacs @xref{Patches}.
204 There's really not much more to tell about the web site. It is just
205 your normal run-of-the-mill web site. And as everyone knows, HTML
206 blows goats so it doesn't get updated anywhere near as often as it
207 should. We do have a @email{webmaster@@sxemacs.org, Webmaster}, so if
208 you do have any comments about the site, you should direct them there.
209 Or, alternatively, @email{sxemacs-devel@@sxemacs.org, SXEmacs Devel}
212 @node Download Site, IRC, Web Site, Online Presence
213 @comment node-name, next, previous, up
214 @chapter SXEmacs Download Site
221 @uref{http://downloads.sxemacs.org/releases/, SXEmacs release downloads} is
222 where you'll find release tarballs and release to release patches
223 available for download.
225 @uref{http://downloads.sxemacs.org/snapshots/, SXEmacs snapshot downloads}
226 is where you can find snapshot tarballs which are uploaded from time
227 to time. Please note that these snapshots can sometimes be very
230 If you would like something made available for download at the SXEmacs
231 download site, contact @sye{}.
233 @node IRC, Merchandise, Download Site, Online Presence
234 @comment node-name, next, previous, up
235 @chapter SXEmacs on IRC
241 Developers official communcation platform is the mailing list provided
242 at sxemacs.org. However, to discuss problems and assist users more
243 efficiently there is an official IRC channel.
245 SXEmacs IRC channel @dfn{#sxemacs} is located at freenode (formerly
246 known as OPN). Please use following URI to refer to it:
248 @uref{irc://irc.freenode.net/#sxemacs}
250 @subheading Various IRC HowTOs
254 Connecting to the network and joining the channel
256 Fire up your favourite irc client and use:
257 @code{/server irc.freenode.net} to connect to the network and
258 @code{/join #sxemacs} to join the community.
260 HowTo become a respected regular
262 Okay, you've decided to be active on IRC and hopefully help other
263 users. You have joined the channel and idle around thirsting for hard
264 problems by helpless users.
266 In that case you will have to have a reliable (not-changing) nickname
267 that is linked to your person in order to refer to you. This will help
268 us in blaming you if you misdirect users with your answers and even help
269 us to praise you if you convinced RMS to switch to SXEmacs ;)
271 Therefore, freenode provides a mechanism to eternalise yourself via
272 the nickname you carry. Use @code{/nickserv register <password>}
273 to engrave your nickname for your personal use.
275 This nickname is yours from now on. To identify yourself to freenode
276 use @code{/nickserv identify <samepasswordasabove>}
278 Your user mode will be changed to @dfn{+e} in case of successful
281 Whenever you see unscrupulous people carrying your nickname or your
282 nickname is ghosted because of a reconnection, you can just
283 @code{/nickserv ghost <yournickname> <yourpassword>} to send the
284 other client to oblivion.
286 Okay, now that you've registered yourself with freenode, you're
287 nickname can be referred to, independently from whether you are
288 carrying that nick or not. Just do @code{/nickserv info <nickname>}
289 to obtain some information on a nickname you see and like to refer
292 HowTo to be listed in the channel access list
294 There is no influence on this access list on the users and developer's
295 side. It is merely up to the project lead who has control over it.
299 The only way to get one is to ask the project lead (JackaLX).
303 You don't have an IRC client but still want to shoot the breeze with
304 us on IRC? Then we have an answer for you@dots{}
305 @uref{http://www.sxemacs.org/irc.html, Chat from the web}.
308 @node Merchandise,, IRC, Online Presence
309 @comment node-name, next, previous, up
310 @chapter SXEmacs Merchandise
317 @cindex retail therapy
322 At @uref{http://store.sxemacs.org/, The SXEmacs Store} you will find
323 for sale various cool and sexy goodies sporting the SXEmacs logo. The
324 proceeds from all purchases go toward covering the costs involved in
325 the upkeep of the SXEmacs project. Be the first on your street to own
326 a @i{I'm Too Sexy For My Emacs} T-shirt!
328 @node Dispute Resolution, Coding Style, Online Presence, Top
329 @comment node-name, next, previous, up
330 @chapter Dispute Resolution
331 @cindex dispute resolution
332 @cindex resolution, dispute
333 @cindex resolving disputes
334 @cindex disputes, resolving
339 When two people agree on everything, one of them isn't needed.
342 I can't remember where that quote comes from so if anyone reading this
343 knows, please let us know so we can give credit where credit is due.
345 We are all mature adults and most of the time we don't let our egos get
346 in the way of getting things done. But human nature being what it is
347 means that from time to time we'll have conflict or disagreements. In
348 the vast majority of these cases a resolution will come quickly and
349 easily through reasonable discussion.
351 This section is for those rare occasions that will be the exception to
354 In the event of a unresolvable dispute, the SXEmacs Project Lead,
355 @sye{}, will, at his discretion, take one or more of the following
362 Call a @dfn{vote} @ref{Voting}.
364 Call a @dfn{postponement}. This will mean that all parties will be
365 asked to stop discussing the matter until some date in the future. This
366 future date will be given at the time the SXEmacs Project Lead calls the
367 postponement. The idea here is to give everyone a chance to cool down
368 so that reasonable discussion can continue.
372 * Voting:: Deciding things via ballot
375 @node Voting,, Dispute Resolution, Dispute Resolution
376 @comment node-name, next, previous, up
382 Sometimes things are best decided with a vote. This section describes
383 how these votes are to be held.
385 Who may participate in a vote? Anyone subscribed to the SXEmacs
386 Developers' mailing list, @email{sxemacs-devel@@sxemacs.org}.
388 Who may call a vote? The SXEmacs Project Lead, @sye{}. Of course
389 anyone may ask the Project Lead to call a vote.
391 @subsection Mechanics of the Vote
395 The votes will be cast via email on the SXEmacs Developers' mailing
396 list, @email{sxemacs-devel@@sxemacs.org}.
398 The @dfn{ballot paper} will have the email subject
399 @dfn{[Vote] Subject of vote}. The body of this email will contain the
400 details of the ballot. The actual questions or points that make up what
401 is being voted on should be in a form that makes it easy to respond to.
402 In other words they should be either multiple choice or yes/no type
405 Each person wishing to participate in the vote will simply reply
406 @emph{once} to this email. The reply or @dfn{vote} @emph{must} come to
409 Anyone wishing to abstain need not do anything. Just don't reply to the
412 There will be a time limit restriction on voting on any matter. This
413 time limit will be a minimum of one calendar week from the time the vote
414 is declared @dfn{open}. The vote is declared @dfn{open} with the
415 posting of the initial ballot email (with the subject prefix of
420 @subsection Deciding the Outcome
422 As soon as practicable after the vote closes (when the time limit has
423 expired) the SXEmacs Project Lead will tally up all the votes and post
424 the results to the SXEmacs Developers' mailing list,
425 @email{sxemacs-devel@@sxemacs.org}. This post will have the email
426 subject @dfn{[Vote Results] Subject of vote}.
428 For an issue to be decided via vote it must receive the majority of the
429 total number of votes with a minimum of four votes.
448 @node Coding Style, Patches, Dispute Resolution, Top
449 @comment node-name, next, previous, up
450 @chapter Coding Style
452 @cindex style, coding
456 SXEmacs has two main programming languages, Emacs Lisp, and C, therefore
457 we need two sets of coding styles.
459 @subsection Coding Style -- Emacs Lisp
460 @cindex emacs lisp coding style
461 @cindex coding style, emacs lisp
462 @cindex lisp coding style
463 @cindex coding style, lisp
465 Read @pxref{(lispref)Style Tips}
467 Please take particular note of@dots{}
470 Don't make a habit of putting close-parentheses on lines by
471 themselves; Lisp programmers find this disconcerting. Once in a
472 while, when there is a sequence of many consecutive
473 close-parentheses, it may make sense to split them in one or two
477 The only other thing I have to say about lisp coding style is to keep
478 your lines @emph{under} 80 columns in length.
480 @subsection Coding Style -- C
481 @cindex C coding style
482 @cindex coding style, C
485 First off, I'd suggest printing out a copy of the GNU coding standards,
486 and NOT read it. Burn them, it's a great symbolic gesture.
492 * General C Style:: What you should use everywhere
493 * SXEmacs Specific Style:: Our idiosyncrasies
496 @node General C Style, SXEmacs Specific Style, Coding Style, Coding Style
497 @chapter General C Style
498 @cindex C coding style
499 @cindex coding style, C
500 @cindex general coding style
501 @cindex coding style, general
503 SXEmacs C code follows, to a large degree, the coding style of the Linux
504 Kernel source. Much of this section is a verbatim copy of
505 @file{./Documentation/CodingStyle} from the Linux kernel sources.
509 @cindex indentation coding style
510 @cindex coding style, indentation
512 Tabs are 8 characters, and thus indentations are also 8 characters.
513 There are heretic movements that try to make indentations 4 (or even 2!)
514 characters deep, and that is akin to trying to define the value of PI to
517 Rationale: The whole idea behind indentation is to clearly define where
518 a block of control starts and ends. Especially when you've been looking
519 at your screen for 20 straight hours, you'll find it a lot easier to see
520 how the indentation works if you have large indentations.
522 Now, some people will claim that having 8-character indentations makes
523 the code move too far to the right, and makes it hard to read on a
524 80-character terminal screen. The answer to that is that if you need
525 more than 3 levels of indentation, you're screwed anyway, and should
528 In short, 8-char indents make things easier to read, and have the added
529 benefit of warning you when you're nesting your functions too deep.
532 Don't put multiple statements on a single line unless you have something
536 if (condition) do_this;
537 do_something_everytime;
540 Outside of comments and documentation, spaces are never used for
541 indentation, and the above example is deliberately broken.
543 @cindex coding style, whitespace
545 Don't leave whitespace at the end of lines. There is a
546 @file{whitespace.el} which you can get from
547 @uref{http://www.dsmit.com/lisp/}. Use it.
549 @heading Breaking long lines and strings
551 Coding style is all about readability and maintainability using commonly
554 The limit on the length of lines is 80 columns and this is a hard limit.
556 Statements longer than 80 columns will be broken into sensible chunks.
557 Descendants are always substantially shorter than the parent and are placed
558 substantially to the right. The same applies to function headers with a long
559 argument list. Long strings are as well broken into shorter strings.
563 fun(int a, int b, int c)
566 printf("Warning this is a very very very long printf with "
567 "3 parameters a: %u b: %u "
568 "c: %u \n", a, b, c);
574 @heading Placing Braces
576 @cindex coding style, braces
577 The other issue that always comes up in C styling is the placement of
578 braces. Unlike the indent size, there are few technical reasons to
579 choose one placement strategy over the other, but the preferred way, as
580 shown to us by the prophets Kernighan and Ritchie, is to put the opening
581 brace last on the line, and put the closing brace first, thusly:
589 However, there is one special case, namely functions: they have the
590 opening brace at the beginning of the next line, thus:
599 Heretic people all over the world have claimed that this inconsistency
600 is ... well ... inconsistent, but all right-thinking people know that
601 (a) K&R are @emph{right} and (b) K&R are right. Besides, functions are
602 special anyway (you can't nest them in C).
604 Note that the closing brace is empty on a line of its own, @emph{except}
605 in the cases where it is followed by a continuation of the same statement,
606 ie a "while" in a do-statement or an "else" in an if-statement, like this:
611 @} while (condition);
619 @} else if (x > y) @{
628 @cindex coding style, naming
629 C is a Spartan language, and so should your naming be. Unlike Modula-2
630 and Pascal programmers, C programmers do not use cute names like
631 @var{ThisVariableIsATemporaryCounter}. A C programmer would call that
632 variable @var{tmp}, which is much easier to write, and not the least more
633 difficult to understand.
635 HOWEVER, while mixed-case names are frowned upon, descriptive names for
636 global variables are a must. To call a global function "foo" is a
639 GLOBAL variables (to be used only if you _really_ need them) need to
640 have descriptive names, as do global functions. If you have a function
641 that counts the number of hidden buffers, you should call that
642 @code{count_hidden_buffers()} or similar, you should @emph{not} call it
645 Encoding the type of a function into the name (so-called Hungarian
646 notation) is brain damaged - the compiler knows the types anyway and can
647 check those, and it only confuses the programmer. No wonder MicroSoft
648 makes buggy programs.
650 LOCAL variable names should be short, and to the point. If you have
651 some random integer loop counter, it should probably be called @var{i}.
652 Calling it @var{loop_counter} is non-productive, if there is no chance
653 of it being mis-understood. Similarly, @var{tmp} can be just about any
654 type of variable that is used to hold a temporary value.
656 If you are afraid to mix up your local variable names, you have another
657 problem, which is called the @dfn{function-growth-hormone-imbalance
662 @cindex coding style, functions
663 Functions should be short and sweet, and do just one thing. They should
664 fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24,
665 as we all know), and do one thing and do that well.
667 A function's return type should be put on a line by itself like this:
671 main(int argc, char **argv)
678 This also helps things like @code{etags}.
680 The maximum length of a function is inversely proportional to the
681 complexity and indentation level of that function. So, if you have a
682 conceptually simple function that is just one long (but simple)
683 case-statement, where you have to do lots of small things for a lot of
684 different cases, it's OK to have a longer function.
686 However, if you have a complex function, and you suspect that a
687 less-than-gifted first-year high-school student might not even
688 understand what the function is all about, you should adhere to the
689 maximum limits all the more closely. Use helper functions with
690 descriptive names (you can ask the compiler to in-line them if you think
691 it's performance-critical, and it will probably do a better job of it
692 than you would have done).
694 Another measure of the function is the number of local variables. They
695 shouldn't exceed 5-10, or you're doing something wrong. Re-think the
696 function, and split it into smaller pieces. A human brain can
697 generally easily keep track of about 7 different things, anything more
698 and it gets confused. You know you're brilliant, but maybe you'd like
699 to understand what you did 2 weeks from now.
704 @cindex coding style, commenting
705 @cindex coding style, comments
706 Comments are good, but there is also a danger of over-commenting.
707 @emph{NEVER} try to explain @emph{HOW} your code works in a comment:
708 it's much better to write the code so that the @emph{working} is
709 obvious, and it's a waste of time to explain badly written code.
711 Generally, you want your comments to tell @emph{WHAT} your code does, not
712 @emph{HOW}. Also, try to avoid putting comments inside a function body:
713 if the function is so complex that you need to separately comment parts of
714 it, you should probably go back to section on @dfn{Functions} for a while.
715 You can make small comments to note or warn about something particularly
716 clever (or ugly), but try to avoid excess. Instead, put the comments at
717 the head of the function, telling people what it does, and possibly WHY it
720 A comment in C looks like @code{/* a comment */}. A comment in C++
721 looks like @code{// a comment}. Don't get them confused and don't
722 @emph{ever} use C++ style comments.
724 This style of commenting in C @emph{is} acceptable:
728 * A comment style in C that is quite often used
729 * for multi-line comments.
736 @cindex coding style, macros
737 Names of macros defining constants and labels in enums are capitalised.
740 #define CONSTANT 0x12345
743 Enums are preferred when defining several related constants.
745 CAPITALISED macro names are appreciated but macros resembling functions
746 may be named in lower case.
748 Generally, inline functions are preferable to macros resembling functions.
750 Macros with multiple statements should be enclosed in a do - while block:
753 #define macrofun(a,b,c) \
760 @subheading Things to avoid when using macros:
764 macros that affect control flow:
774 is a @emph{very} bad idea. It looks like a function call but exits the "calling"
775 function; don't break the internal parsers of those who will read the code.
778 macros that depend on having a local variable with a magic name:
781 #define FOO(val) bar(index, val)
784 might look like a good thing, but it's confusing as hell when one reads the
785 code and it's prone to breakage from seemingly innocent changes.
788 macros with arguments that are used as l-values: FOO(x) = y; will
789 bite you if somebody e.g. turns FOO into an inline function.
792 forgetting about precedence: macros defining constants using expressions
793 must enclose the expression in parentheses. Beware of similar issues with
794 macros using parameters.
797 #define CONSTANT 0x4000
798 #define CONSTEXP (CONSTANT | 3)
802 @heading Further Reading
803 @cindex further reading
804 @cindex coding style, further reading
806 The C Programming Language, Second Edition
807 by Brian W. Kernighan and Dennis M. Ritchie.
808 Prentice Hall, Inc., 1988.
809 ISBN 0-13-110362-8 (paperback), 0-13-110370-9 (hardback).
810 @uref{http://cm.bell-labs.com/cm/cs/cbook/}
812 The Practice of Programming
813 by Brian W. Kernighan and Rob Pike.
814 Addison-Wesley, Inc., 1999.
816 @uref{http://cm.bell-labs.com/cm/cs/tpop/}
819 GNU manuals - where in compliance with K&R and this text - for cpp, gcc,
820 gcc internals and indent, all available from @uref{http://www.gnu.org/}
822 WG14 is the international standardization working group for the programming
823 language C, @uref{http://std.dkuug.dk/JTC1/SC22/WG14/}
825 @node SXEmacs Specific Style,,General C Style, Coding Style
827 @chapter SXEmacs Specific Style
828 @cindex sxemacs specific coding style
829 @cindex coding style, sxemacs specific
831 This section was lifted almost word for word from the XEmacs
832 @file{CODING-STANDARDS} by Ben Wing.
834 @heading Specially-prefixed functions/variables:
835 @cindex coding style, function prefix
836 @cindex coding style, variable prefix
837 @cindex coding style, functions
838 @cindex coding style, variables
841 All global C variables whose value is constant and is a symbol begin
842 with a capital Q, e.g. @var{Qkey_press_event}. (The type will always be
846 All other global C variables whose value is a @dfn{Lisp_Object} (this
847 includes variables that forward into Lisp variables plus others like
848 @var{Vselected_console}) begin with a capital V.
851 No C variables whose value is other than a @dfn{Lisp_Object} should begin
852 with a capital V. (This includes C variables that forward into
853 integer or boolean Lisp variables.)
854 All global C variables whose value is a struct Lisp_Subr begin with a
855 capital S. (This only occurs in connection with DEFUN ()).
858 All C functions that are Lisp primitives begin with a capital F,
859 and no others should begin this way.
862 @heading Functions for manipulating Lisp types:
863 @cindex coding style, functions
866 Any function that creates an empty or mostly empty Lisp object
867 should begin allocate_(). (*Not* make_().) (Except, of course,
868 for Lisp primitives, which usually begin Fmake_()).
871 Any function that converts a pointer into an equivalent Lisp_Object
872 should begin make_().
875 Any function that converts a Lisp_Object into its equivalent pointer
876 and checks the type and validity of the object (e.g. making sure
877 it's not dead) should begin decode_().
880 Any function that looks up a Lisp object (e.g. buffer, face) given
881 a symbol or string should begin get_(). (Except, of course, for
882 Lisp primitives, which usually begin Fget_()).
887 Any header-file declarations of the sort
893 go into the @dfn{types} section of @file{lisp.h}.
896 @node Patches, Feature Requests, Coding Style, Top
897 @comment node-name, next, previous, up
900 @cindex contributions
904 Ideally, the best way to get your patches into the SXEmacs code base is
905 to have @s{} fetch them directly from your git repo. If, for any
906 reason you are not able to set up a repository with read-only access
907 for (at least) @s{}, that doesn't mean that you can't still contribute
908 your patches and code.
910 You can check how to setup a publicly accessible repo at @xref{Setting
911 up a publicly accessible repo}.
913 There are a number of different situations and circumstances that you
914 may find yourself in with regards to contributing to the SXEmacs
915 project. I'll try to cover the main ones here, but please note that
916 they @emph{all} have two things in common@dots{}
920 A diff is always sent to
921 @email{sxemacs-patches@@sxemacs.org, SXEmacs Patches}.
923 The diff is always in @dfn{unified} format
924 @code{diff -u oldfile newfile}
928 * Sending a patch from a git repo::
929 Procedure to send a patch from a git repo,
930 be it a publicly accessible one, or just a
931 private clone from the master repo.
932 * Vanilla sources (no repo):: Just the source tree that isn't under
936 @node Sending a patch from a git repo, Vanilla sources (no repo), Patches, Patches
937 @comment node-name, next, previous, up
938 @chapter Sending a patch from a git repo
940 @cindex contributions
944 Firstly, if you can set up an accessible remote repo, please do so.
945 You can see how easy it is in section @xref{Setting up a publicly
946 accessible repo}. It will make things so much easier for everyone.
947 We do understand that there may be some valid reasons why you can't,
948 and that is okay, this section still provides a valid workflow.
951 @subheading Preparing a patch from a git repo
953 Are you in the right place? You cloned the SXEmacs sources with
954 @code{git clone http://git.sxemacs.org/sxemacs}.
956 Yes? OK, great, read on.
958 Your workflow should run something along these lines@dots{}
962 @code{git pull} from your master branch to sync up with the main
965 @code{git checkout -b mybugfix} to create and checkout a new branch.
966 You can call it whatever you like, just as long as @emph{you} know
967 what it's about. (Yeah, we recommend that you do all your work on
968 branches and keep your master branch as pristine as possible).
970 hack hack edit edit fix fix hack
972 Test! If all is good, proceed. If not, return to the previous step.
974 Depending on how you like to deal with change logs, and if the changes
975 were small and trivial or detailed and large:
979 @code{git commit -sam "Summary of changes"} For use with small quick
980 changes that don't really warrant verbose logs to document them.
982 @code{git commit -sa} This form will fire up an editor for you to
983 write your change logs in@footnote{You can set which editor to use
984 with @code{git config --global core.editor my_fav_editor}. @s{} has
985 his set to a shell function called @dfn{edit} which fires up gnuclient
986 if SXEmacs is running, or SXEmacs if not.}.
988 @code{git commit -saF mylogfile} Use this form for the times when you
989 have logged your changes as you went to the file @file{mylogfile}.
992 Please take note, that whichever commit command you use, to
993 @emph{always} use the @code{-s} option to add a @dfn{Signed-off-by}
994 entry to the log. This will indicate that you played some role in
995 getting the patch into the code base, and, perhaps more importantly,
996 you had permission to do so@footnote{There might be
997 licencing/copyright things to be aware of, especially in the case of
998 working on SXEmacs either for your employer, or during your employer's
1001 For patches that you're submitting to the main SXEmacs code base that
1002 have originated from somebody else (maybe you have a small team of
1003 sub-developers working for you), the @dfn{Signed-off-by} entry also
1004 indicates that you have reviewed, tested, and approved the patch. And
1005 also, the original author has permission to submit it.
1007 @code{git checkout master} To flip back to your master branch.
1009 @code{git merge --no-ff mybugfix} To merge the changes from the
1010 @dfn{mybugfix} branch into master. The @code{--no-ff} forces git to
1011 create a new commit object even if a fast-forward could have been used
1012 to carry out the merge.
1014 At this point everything that was in the @dfn{mybugfix} branch is now
1015 in your master branch, so you no longer need it. You can safely delete
1016 it with @code{git branch -d mybugfix}.
1018 Now if you have a publicly accessible repo, you should do:
1020 @code{git push myremote master} To push the changes to your publicly
1021 accessible repo, @dfn{myremote}.
1024 If your repos is private, it is safe to skip the push and just advance
1027 @subheading @anchor{Patch Submission}Patch Submission
1029 At this point, your changes are ready for @s{} to be incorporated into
1030 the main SXEmacs code base. All you need to do is let him know, and
1031 you can easily do that with the following 2 git commands:
1035 @code{git format-patch --add-header="X-Git-Repo: REPO-URL" \@*
1037 --subject-prefix="P-Req" --numbered -o DIR origin}
1039 @code{git send-email \@*
1041 --to="SXEmacs Patches <sxemacs-patches@@sxemacs.org>" \@*
1043 --from="$(git config user.name) <$(git config user.email)>" DIR}
1046 If you not have have a publicly accessible repository, the SXEmacs
1047 developers can't pull in your changesets directly from you. Instead,
1048 once your patch hits the mailing list and is approved, it will be
1049 applied manually to the SXEmacs code base.
1051 You could, in theory, use a post-commit hook, but I'd not recommend
1052 it. Think about the situation where you are working on something
1053 fairly big. You'd most likely commit several times before you have
1054 things ready for us.
1056 If you have a publicly accessible repo, be sure to setup automation
1057 like in @xref{Automation}.
1059 @node Vanilla sources (no repo),, Sending a patch from a git repo, Patches
1060 @comment node-name, next, previous, up
1061 @chapter Vanilla sources (no repo)
1063 @cindex contributions
1067 Are you in the right place? All you have is a SXEmacs source tarball
1068 and you don't have @file{git} installed.
1070 Yes? OK, great, read on.
1072 You will have the toughest time of it I'm afraid because you will have
1073 to do everything manually. But it isn't too bad. No worse than for any
1076 Your hacking cycle will look something like this:
1080 Unpack the source tarball somewhere and @emph{don't touch it}. This
1081 will be your pristine sources.
1083 Make a copy of your pristine sources somewhere else. This will be your
1084 working tree where you make your changes.
1086 cd into your working tree and hack hack hack
1088 Jump out of your working tree and do:
1089 @code{diff -urNp pristine-tree working-tree > my-sxemacs.diff}
1091 A note of caution here: Please ensure that you are diff'ing clean
1092 trees. In other words, run @code{make distclean} in your working tree
1093 @emph{before} creating the diff.
1095 Send @file{my-sxemacs.diff} (gzip'd if large) as a MIME attachment
1096 together with a detailed description of your changes to the
1097 @email{sxemacs-patches@@sxemacs.org, SXEmacs Patches} mailing list.
1100 @node Feature Requests, Support Requests, Patches, Top
1101 @comment node-name, next, previous, up
1102 @chapter Feature Requests
1103 @cindex request, feature
1105 From time to time someone will wander into the mailing list or our
1106 IRC channel saying something like "ya know, SXEmacs is cool, but it
1107 would truly @emph{rock} if it had @dfn{fooble-klangers}. How 'bout
1108 it guys? Can somebody please add @dfn{fooble-klangers} to SXEmacs?".
1110 @emph{That's} a @dfn{Feature Request}.
1112 It doesn't matter what a @dfn{fooble-klanger} is. It doesn't matter
1113 if having said @dfn{fooble-klanger} would make SXEmacs rock or not.
1114 What @strong{DOES MATTER} is that we acknowledge the request. And we
1115 acknowledge it quickly.
1117 So how quick is quickly? Anything greater than 48 hours is @emph{slow}.
1118 We should try to get an initial ack out within 24 hours of the feature
1119 request hitting the mailing list@footnote{All legitimate feature requests
1120 should eventually end up on the @uref{http://issues.sxemacs.org/, SXEmacs
1121 Issue Tracker}.}. I totally understand that the 24 hour turn-around
1122 won't always be possible. Often there'll be extenuating circumstances
1123 (I'm writing this right now in the middle of a 2 week period with no
1124 internet connection).
1126 The acknowledgment doesn't need to be anything more than just that, an
1127 acknowledgment. You don't need to have a 100,000 lines of working
1128 code that proves how much @dfn{fooble-klangers} make or don't make
1129 SXEmacs rock before you let the guy know that he isn't talking to a
1132 A feature request can only end up in one of 3 scenarios...
1143 Of those, #3 is @strong{UNACCEPTABLE}! That means, if you see a
1144 feature request that is more than 48 hours old and hasn't been
1145 acknowledged, it is @strong{YOUR} responsibility to do something about
1148 A feature request on our @uref{http://issues.sxemacs.org/, Issue
1149 Tracker} is a issue that has the @dfn{FeatReq} flag set and the
1150 severity set to @dfn{enhancement}.
1153 @node Support Requests, Bug Reports, Feature Requests, Top
1154 @comment node-name, next, previous, up
1155 @chapter Support Requests
1156 @cindex request, support
1158 Support requests are a call for help from our users and as such have
1159 @emph{top priority}. Much of @xref{Feature Requests}, applies equally
1162 Support requests are @emph{everyone's} responsibility, so if you see
1163 one and you think you can help, do so.
1165 @node Bug Reports, Making Releases, Support Requests, Top
1166 @comment node-name, next, previous, up
1167 @chapter Bug Reports
1170 Bug reports are a @emph{good} thing. They show that people are using
1171 the code that you spent so much time and effort in writing. Bug
1172 reports are an opportunity to improve SXEmacs. Never be scared of bug
1173 reports. Never get annoyed or upset by bug reports. Welcome them.
1174 As a matter of fact, worry if you don't see any bug reports. That
1175 would mean we aren't working hard enough. :-)
1177 All bug reports have to be submitted to our
1178 @uref{http://issues.sxemacs.org/, Issue Tracker}. So it goes without
1179 saying that you already have an account on our Issue Tracker, and if
1180 you don't, go get one @emph{now}.
1182 Because the Issue Tracker is just that, it @dfn{tracks} issues, all
1183 followups and correspondence concerning a bug @emph{must} be added via
1184 the issue tracker itself. @emph{DO NOT} follow up to a bug report on
1185 the mailing list. If a bug report is submitted to the mailing list
1186 initially (because the submitter wasn't aware of our Issue Tracker),
1187 the person submitting the report should be directed to our
1188 @uref{http://issues.sxemacs.org/, Issue Tracker}. If they are
1189 unwilling or unable to do so, one of us will do so.
1191 If a bug report results in a patch and merge request, the summary of
1192 the patch log should contain the text: "(Closes bug #n)", where `n' is
1193 the number that our Issue Tracker has assigned to that bug. The bug
1194 should be marked as "fixed" (stating in which revision) on the Issue
1195 Tracker. It should not be marked "Closed" until just prior to a
1196 release. Closing bugs is the job and responsibility of the project
1197 lead, or whoever is responsible for making releases.
1200 @node Making Releases, New Features, Bug Reports, Top
1201 @comment node-name, next, previous, up
1202 @chapter Making Releases
1205 From time to time, at the project lead's discretion, a release
1206 will be made and tarballs created and made available on
1207 @uref{http://downloads.sxemacs.org/releases/, the SXEmacs download site}.
1209 The decision as to @emph{when} to cut a release is generally
1210 influenced by two factors:
1214 How stable the code base is currently.
1216 Whether the changes since the last release warrant a new release.
1219 The minimum number of revisions between releases is one. The maximum
1220 number of revisions between releases is, well, there is no maximum.
1222 The actual steps involved in cutting a release are:
1226 Finalise things like...
1229 Update @file{etc/NEWS}
1231 Make sure @file{INSTALL}, @file{PROBLEMS} etc are up to date.
1233 Update @file{sxemacs.texi} at@dots{}
1239 Update the codename and version in @file{autogen.sh}
1241 Update the versioning macros in this document.
1244 Commit those updates.
1246 @code{git commit -sam "SXEmacs v@nver{} is released!"}
1248 Create a new tag which will be the version number of this release.
1250 @code{git tag -s v@nver{} -m "SXEmacs v@nver{}"}
1252 Push it to the public repo.
1254 @code{git push --tags origin master}
1258 (in the release working directory)
1261 git archive --format=tar \
1262 --prefix=sxemacs-@nver{}/ HEAD | \
1263 (cd ~/upload && tar xf -)
1267 Clean out the working directory and do autotool preparations.
1270 HAMMER=1 ./autogen.sh
1274 Copy the autotool files to the exported tree
1277 mkdir -v ~/upload/sxemacs-@nver{}/libltdl &&
1278 for f in $(git ls-files --others -i --exclude-standard); do
1279 cp -va $@{f@} ~/upload/sxemacs-@nver{}/$@{f@}
1287 git log --stat v@cver{}..v@nver{} > /tmp/sxemacs-@nver{}/ChangeLog
1295 for type in bz2 gz lzma xz; do
1296 tar --create --owner=0 --group=0 --auto-compress --file \
1297 sxemacs-@nver{}.tar.$@{type@} sxemacs-@nver{}
1298 md5sum sxemacs-@nver{}.tar.$@{type@} > sxemacs-@nver{}.tar.$@{type@}.md5
1299 gpg --detach-sign --armor \
1300 --output sxemacs-@nver{}.tar.$@{type@}.asc sxemacs-@nver{}.tar.$@{type@}
1304 @c replace this with the appropriate git magic
1305 Create a diff against the previous version.
1308 Unpack the previous release's tarball
1311 diff -urNp sxemacs-@cver{} sxemacs-@nver{} > sxemacs-@cver{}-@nver{}.diff
1312 gzip sxemacs-@cver{}-@nver{}.diff
1317 Create md5 and gpg sig for diff file.
1319 See items describing this for the release tarball.
1322 Move the tarball, diff, GnuPG sigs, and md5sums to
1323 @uref{http://downloads.sxemacs.org/releases/, SXEmacs Download Site}.
1326 Rename the @file{LATEST-IS-foo} file.
1328 mv LATEST-IS-@cver{} LATEST-IS-@nver{}
1332 Update www.sxemacs.org:
1336 Update @file{download.html}
1338 Add @file{ChangeLog-@nver{}} to the website
1340 Update @file{index.html}
1344 Send a release announcement to @email{sxemacs-devel@@sxemacs.org,
1345 SXEmacs Devel} and comp.emacs.xemacs.
1348 Make a new release and announcement on Freshmeat (our FM id: 52281)
1351 Commit the first patch to the next version, which would be adding a
1352 @file{ChangeLog.d/ChangeLog-@nver}
1356 @node New Features, Compatibility, Making Releases, Top
1357 @comment node-name, next, previous, up
1358 @chapter New Features
1359 @cindex feature, new
1361 How do you get a new feature into SXEmacs? It's not hard, but
1362 remember this, we look at any new feature in this order of
1367 Tested working code.
1369 A plan of action with @dfn{Proof of concept} code.
1371 A plan of action with a willingness to write the code.
1373 An idea with a willingness to move it to a real plan and then to
1376 An idea with a willingness to help test any code resulting from it.
1378 @dfn{Hey, wouldn't it be cool if...}
1381 Don't be disheartened if you aren't a master programmer, quite often
1382 the best new features and ideas come from non-programmers. All too
1383 often the people writing the code get caught up in what they are doing
1384 and find it hard to see things from @dfn{outside of the box}. Anyone
1385 can help with ideas and with testing new code and features.
1387 Any new feature begins with an idea, and at @emph{that} point somebody
1388 should post that idea to @email{sxemacs-devel@@sxemacs.org, SXEmacs
1391 @node Compatibility, Copyright and Licencing, New Features, Top
1392 @comment node-name, next, previous, up
1393 @chapter Compatibility
1394 @cindex compatibility, xemacs
1395 @cindex compatibility, emacs
1397 All I'll say about this is that for the foreseeable future, SXEmacs
1398 will remain 100% backwardly compatible with XEmacs where emacs lisp is
1399 concerned. An emacs lisp package or library that runs on XEmacs
1400 @emph{will} run on SXEmacs.
1402 If you find a place where this isn't true, you should report it as a
1403 bug, @xref{Bug Reports}.
1405 If you find areas where SXEmacs is incompatible with GNU/Emacs at the
1406 emacs lisp level, that is an issue between GNU/Emacs and XEmacs.
1408 @node Copyright and Licencing, Developer Recruitment, Compatibility, Top
1409 @comment node-name, next, previous, up
1410 @chapter Copyright and Licencing
1412 SXEmacs is an @dfn{Open Source} project. Because of that we can only
1413 accept code and contributions that are covered by an Open Source
1416 We differ from the GNU/Emacs project in that we will accept any
1417 @dfn{OSI} approved Open Source licence, not just the GNU GPL. That
1418 means that if you are more comfortable with, say, the BSD licence,
1421 We also won't ask you to reassign your copyright to anyone else. If
1422 you want to reassign your copyright to the FSF (for example), you can,
1423 but we won't reject any contributions from you because you haven't.
1424 @footnote{If you contribute code to SXEmacs that you want included in
1425 GNU/Emacs you will have to reassign copyright to the FSF. Please
1426 understand that that is a GNU/Emacs requirement and @emph{not} a
1427 SXEmacs requirement}
1429 @subheading SXEmacs and your Employer
1430 This is @strong{very} important. If you write code for SXEmacs either
1431 on your employer's time (while you are at work), or using your
1432 employer's resources (hardware, software, electricity, furniture, etc)
1433 then your employer may have legal copyright of your work.
1435 @strong{PLEASE} be up front with your employer and clear it with them
1436 @strong{before} you write anything for SXEmacs. It is OK and
1437 perfectly acceptable to submit contributions to SXEmacs that are
1438 copyrighted to your employer, providing (and this is the key) your
1439 employer is willing to release the code under an approved OSI
1442 Don't overlook or dismiss this. It is here to safeguard you, your
1443 employer, the SXEmacs project as a whole, and @sy{} personally.
1445 @subheading Documentation Licences
1446 Please don't licence any documentation under the FSF's new @dfn{Free
1447 Documentation Licence}. This isn't a slight against the FSF or the
1448 GNU project, it is just because it will mean that our documentation
1449 would not be able to be included in XEmacs. It may even cause
1450 problems going the other way as well (XEmacs to SXEmacs).
1452 For that reason, we'll err on the side of caution.
1454 @node Developer Recruitment, Making/Altering Policies, Copyright and Licencing, Top
1455 @comment node-name, next, previous, up
1456 @chapter Developer Recruitment
1459 We don't actively try to recruit new developers in any kind of formal
1460 way. What we do is use SXEmacs for everything everyday and not hide
1461 the fact that we do. :-) That in itself makes people curious and some
1462 ask about this thing called @dfn{SXEmacs}. Show them what it is,
1463 point them to the @uref{http://www.sxemacs.org/, web site}, encourage
1464 them to subscribe to @email{sxemacs-devel@@sxemacs.org, SXEmacs
1465 Devel}, and even help them get an account on
1466 @uref{http://issues.sxemacs.org/, Our Issue Tracker}. And low and
1467 behold! We have a new developer.
1469 One recruitment tool that we do have is @dfn{sxemacs.org} email
1470 addresses. If you'd like one, contact @sye{}. Then you can use that
1471 email address whenever and whereever you like. Hmm, perhaps not
1472 @emph{everywhere}, it might not look so good if you use it for log in
1473 details to a pr0n site. :-P
1475 @node Making/Altering Policies, Version Control, Developer Recruitment, Top
1476 @comment node-name, next, previous, up
1477 @chapter Making/Altering Policies
1478 @cindex policies, changing
1480 How do you get these policies and proceedures changed? Simple. Just
1481 post to @email{sxemacs-devel@@sxemacs.org, SXEmacs Devel} stating
1482 where what how when and why. If it is non-controversial and makes
1483 sense, it'll probably be accepted quickly. If not, there could be
1484 lengthy @dfn{discussions} and possibly even a vote @xref{Voting}.
1486 @sy{} will always have the final word and make the ultimate decision,
1487 but he isn't an immovable force, his mind can be changed and he
1488 @emph{does} listen to what the rest of the project is saying. :-)
1490 @node Version Control, Concept Index, Making/Altering Policies, Top
1491 @comment node-name, next, previous, up
1492 @chapter Version Control
1493 @cindex version control
1498 The SXEmacs Project keeps control of its sources with git, starting
1499 with version 22.1.13.
1500 The main repository is that of the Project Lead (@sy{}). It is
1504 http://git.sxemacs.org/sxemacs
1507 Checking out a copy of SXEmacs is as easy as:
1510 git clone http://git.sxemacs.org/sxemacs
1513 See how to patches in chapter @xref{Patches}.
1516 * Setting up a publicly accessible repo::
1517 A git repo that others have read
1519 * Setting up a private repos:: A git repo only you have access to.
1520 * Other Developers' Repositories:: Git repos of regular developers of
1525 @node Setting up a publicly accessible repo, Setting up a private repos, Version Control, Version Control
1526 @comment node-name, next, previous, up
1527 @chapter Setting up a publicly accessible repo
1528 @cindex version control
1531 @cindex contributions
1533 You only need to read this section if you are able to host a publicly
1534 accessible repo somewhere.
1536 Getting everything set up is really very easy. I think you'll be
1537 quite surprised if you haven't done this sort of thing before. In the
1538 examples below I'm assuming that you have shell access to your remote
1542 user@@localhost ~ $ ssh user@@your.host
1543 user@@host ~ $ mkdir -v sxemacs
1544 user@@host ~ $ cd !$
1545 user@@host ~/sxemacs $ git init --bare
1546 user@@host ~/sxemacs $ echo @dfn{Your Name's SXEmacs Repo} > description
1547 user@@host ~/sxemacs $ exit
1548 user@@localhost ~ $ git clone http://git.sxemacs.org/sxemacs
1549 user@@localhost ~ $ cd sxemacs
1550 user@@localhost ~/sxemacs $ git remote add myremote \
1551 ssh://user@@your.host/~/sxemacs
1554 And that's it! Told you it was easy, didn't I? All you have to do
1555 now is push your local copy to your remote@dots{}
1558 git push myremote master
1562 @subheading @anchor{Automation}Automation
1564 The last two commands for patch submission listed in @xref{Patch
1565 Submission}, @code{format-patch} and @code{send-email} are fairly long
1566 and hairy. You'd no doubt have trouble remembering them. But, never
1567 fear, git has a few tricks up her sleeve to make your life easier.
1569 @subsection Automating with Hooks
1571 If you are lucky enough to @emph{NOT} be using github@footnote{github
1572 is great and may be the ideal solution for you to host your repo
1573 somewhere, but it is inflexible in that you get no shell access, you
1574 can't set up custom hooks, and you are very limited in what git config
1575 settings you can tweak.} to host your publicly accessible repo you can
1576 set up a @dfn{post-receive} hook to automatically send your pull
1577 requests to the SXEmacs mailing list when you push to it.
1579 @subsubsection Setting Up The post-receive Hook
1581 Remember: This hook runs from your publicly accessible repo (your
1582 remote), and @emph{NOT} from your local working directory. It is
1583 called after you push to your remote.
1585 Jump over to your remote now and follow these steps
1589 Take a look in the file
1590 @file{hooks/post-receive.sample}. At the bottom of that file there is
1591 a commented line, that when uncommented would call another script,
1592 @file{post-receive-email}. Check that the path is correct, and
1595 Rename @file{hooks/post-receive.sample} to @file{hooks/post-receive}
1597 Tweak the remote's config with@dots{}
1600 git config hooks.mailinglist \
1601 "SXEmacs Patches <sxemacs-patches@@sxemacs.org>"
1602 git config hooks.envelopesender "Your Name <your@@email>"
1603 git config hooks.emailprefix "[P-Req] "
1604 git config hooks.showrev "git show -C %s; echo"
1607 @code{echo "Your Name's SXEmacs Repo" > description}
1610 Take note that the SXEmacs mailing lists will funnel any post from
1611 non-subscribers into the moderation queue. So make sure that the
1612 address you set @dfn{hooks.envelopesender} to is subscribed to the
1615 Also be aware that using this @dfn{post-receive} hook will mean that
1616 every time you push to your publicly accessible repo, a message will be
1617 sent to sxemacs-patches; this includes instances where you merely
1618 are pulling the latest from mainline and mirroring. Hence, the use of
1619 aliases as discussed below may be preferable.
1621 @subsection @anchor{Automating with Aliases}Automating with Aliases
1623 Git allows you to define aliases that will let you do all kinds of
1624 funky things. Remember those hairy @code{format-patch} and
1625 @code{send-email} commands?
1628 git config alias.sxe-fp 'format-patch --add-header="X-Git-Repo: REPO-URL" \
1629 --subject-prefix="P-Req" --numbered'
1631 git config alias.sxe-sm 'send-email \
1632 --to="SXEmacs Patches <sxemacs-patches@@sxemacs.org>" \
1633 --from="$(git config user.name) <$(git config user.email)>"'
1636 With those 2 aliases set you can get your pull requests in by
1639 @code{git sxe-fp -o DIR origin && git sxe-sm DIR}
1641 @subsection Making Life Even Easier with git config
1643 You can make your life even easier by having git store things in its
1644 config. In this case, you can store those @code{format-patch} and
1645 @code{send-email} command line options in the repo's config@dots{}
1648 git config format.headers "X-Git-Repo: YOUR-REMOTE-URL"
1649 git config format.subjectprefix "P-Req"
1650 git config format.numbered true
1652 git config sendemail.to \
1653 "SXEmacs Patches <sxemacs-patches@@sxemacs.org>"
1654 git config sendemail.from "Your Name <your@@email>"
1657 With those settings, the commands: @code{git format-patch -o DIR
1658 origin}, and @code{git send-email DIR} are now equivalent of the
1659 original long hairy ones mentioned further up.
1661 Be careful when setting up aliases and config settings that you only
1662 make them global if you absolutely have to. All the ones I've shown
1663 here have been repo-specific.
1665 @node Setting up a private repos, Other Developers' Repositories, Setting up a publicly accessible repo, Version Control
1666 @comment node-name, next, previous, up
1667 @chapter Setting up a private repos
1668 @cindex version control
1671 @cindex contributions
1673 Git makes it as easy to create a private repos as getting a checkout
1674 of the source code. In fact, all you need to do is to actually
1675 checkout and you have a repos:
1678 git clone http://git.sxemacs.org/sxemacs
1681 You may want to follow some of the steps in @xref{Automating with
1682 Aliases}, to easy your life when sending patches if you plan to
1683 contribute frequently from this repo. Please note that in this case
1684 you should not reference any REPO-URL.
1686 However if you do plan to contribute frequently, we strongly suggest
1687 you configure a publicly accessible repos.
1689 More details at @xref{Setting up a publicly accessible repo}.
1691 @node Other Developers' Repositories,, Setting up a private repos, Version Control
1692 @comment node-name, next, previous, up
1693 @chapter Other Developers' Repositories
1694 @cindex version control
1697 @cindex contributions
1699 As previously mentioned, the master SXEmacs repo is at:
1701 http://git.sxemacs.org/sxemacs
1704 Some of these repos may not be publicly accessible or may not be
1710 http://git.nelsonferreira.com/sxemacs
1713 And that is it for now. We've only just moved to git and the
1714 main SXEmacs developers haven't set up their repos.
1719 @c http://www.math.tu-berlin.de/~freundt/archives/sxemacs/
1722 @c http://arch.xwem.org/2006/
1725 @c http://arafel.viteno.net:33080/arch/sxemacs/
1728 @c http://www.informatik.uni-bremen.de/~mkhl/sxemacs-mirror/
1729 @c Alexey Mikhailov (karma)
1731 @c http://karma.ezunix.org/arch/2005/
1734 @c http://hynek.in-berlin.de/archive/
1735 @c Horst Burkhardt (PeanutHorst)
1737 @c http://midcom.steveyoungs.com/oss-vc/sxemacs/
1740 @c http://www.heatxsink.com/2005/
1743 And of course the main repo (Steve's) is at:
1745 http://git.sxemacs.org/sxemacs
1746 http://git.sxemacs.org/website (our website is under git too)
1748 @subheading The tla repository for versions upto 22.1.12
1750 The old tla repos at http://arch.sxemacs.org/2010 still exist, and
1751 will remain forever. If you ever need anything from them just install
1752 @code{tla} and leech them with that.
1754 The reason we are keeping them around indefinitely is because the move
1755 to git meant a loss of history. There are tools available for
1756 converting a arch repo to git, but they failed to work in our case
1757 because of the cached revisions in our repos.
1759 @node Concept Index,, Version Control, Top
1760 @unnumbered Concept Index