Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Move and update README.SVN-RULES to README.GIT-RULES

  • Loading branch information...
commit e0d5138660668fc2fb6d111c76ad10ab95e9486e 1 parent 8c4294b
Johannes Schlüter johannes authored

Showing 2 changed files with 124 additions and 146 deletions. Show diff stats Hide diff stats

  1. +124 0 README.GIT-RULES
  2. +0 146 README.SVN-RULES
124 README.GIT-RULES
... ... @@ -0,0 +1,124 @@
  1 +====================
  2 + Git Commit Rules
  3 +====================
  4 +
  5 +This is the first file you should be reading when contributing code via Git.
  6 +We'll assume you're basically familiar with Git, but feel free to post
  7 +your questions on the mailing list. Please have a look at
  8 +http://git-scm.com/ for more detailed information on Git.
  9 +
  10 +PHP is developed through the efforts of a large number of people.
  11 +Collaboration is a Good Thing(tm), and Git lets us do this. Thus, following
  12 +some basic rules with regards to Git usage will::
  13 +
  14 + a. Make everybody happier, especially those responsible for maintaining
  15 + Git itself.
  16 +
  17 + b. Keep the changes consistently well documented and easily trackable.
  18 +
  19 + c. Prevent some of those 'Oops' moments.
  20 +
  21 + d. Increase the general level of good will on planet Earth.
  22 +
  23 +Having said that, here are the organizational rules::
  24 +
  25 + 1. Respect other people working on the project.
  26 +
  27 + 2. Discuss any significant changes on the list before committing and get
  28 + confirmation from the release manager for the given branch.
  29 +
  30 + 3. Look at EXTENSIONS file to see who is the primary maintainer of
  31 + the code you want to contribute to.
  32 +
  33 + 4. If you "strongly disagree" about something another person did, don't
  34 + start fighting publicly - take it up in private email.
  35 +
  36 + 5. If you don't know how to do something, ask first!
  37 +
  38 + 6. Test your changes before committing them. We mean it. Really.
  39 + To do so use "make test".
  40 +
  41 + 7. For development use the --enable-maintainer-zts switch to ensure your
  42 + code handles TSRM correctly and doesn't break for those who need that.
  43 +
  44 +Currently we have the following branches in use::
  45 +
  46 + master The active development branch.
  47 +
  48 + PHP-5.4 Is used to release the PHP 5.4.x series. It still allows for
  49 + larger enhancements.
  50 +
  51 + PHP-5.3 Is used to release the PHP 5.3.x series. This is current
  52 + stable version and is open for bugfixes only.
  53 +
  54 + PHP-5.2 Is used to release the PHP 5.2.x series. It is closed for
  55 + changes now.
  56 +
  57 + PHP-5.1 This branch is closed.
  58 +
  59 + PHP-4.4 This branch is closed.
  60 +
  61 +The next few rules are more of a technical nature::
  62 +
  63 + 1. All changes should first go to the lowest branch (i.e. 5.3) and then
  64 + get merged up to all other branches. If a change is not needed for
  65 + later branches (i.e. fixes for features which where dropped from later
  66 + branches) an empty merge should be done.
  67 +
  68 + 2. All news updates intended for public viewing, such as new features,
  69 + bug fixes, improvements, etc., should go into the NEWS file of the
  70 + *first* to be released version with the given change. In other words
  71 + any NEWS file change only needs to done in one branch.
  72 +
  73 + 3. Do not commit multiple file and dump all messages in one commit. If you
  74 + modified several unrelated files, commit each group separately and
  75 + provide a nice commit message for each one. See example below.
  76 +
  77 + 4. Do write your commit message in such a way that it makes sense even
  78 + without the corresponding diff. One should be able to look at it, and
  79 + immediately know what was modified. Definitely include the function name
  80 + in the message as shown below.
  81 +
  82 + 5. In your commit messages, keep each line shorter than 80 characters. And
  83 + try to align your lines vertically, if they wrap. It looks bad otherwise.
  84 +
  85 + 6. If you modified a function that is callable from PHP, prepend PHP to
  86 + the function name as shown below.
  87 +
  88 +
  89 +The format of the commit messages is pretty simple.
  90 +
  91 +<max 79 characters short description>\n
  92 +\n
  93 +<long description, 79 chars per line>
  94 +\n
  95 +
  96 +An Example from the git project (commit 2b34e486bc):
  97 +
  98 +pack-objects: Fix compilation with NO_PTHREDS
  99 +
  100 +It looks like commit 99fb6e04 (pack-objects: convert to use
  101 +parse_options(), 2012-02-01) moved the #ifdef NO_PTHREDS around but
  102 +hasn't noticed that the 'arg' variable no longer is available.
  103 +
  104 +If you fix some bugs, you should note the bug ID numbers in your
  105 +commit message. Bug ID should be prefixed by "#" for easier access to
  106 +bug report when developers are browsing CVS via LXR or Bonsai.
  107 +
  108 +Example::
  109 +
  110 + Fixed bug #14016 (pgsql notice handler double free crash bug.)
  111 +
  112 +When you change the NEWS file for a bug fix, then please keep the bugs
  113 +sorted in decreasing order under the fixed version.
  114 +
  115 +You can use OpenGrok (http://lxr.php.net/) and gitweb (http://git.php.net/)
  116 +to look at PHP Git repository in various ways.
  117 +
  118 +
  119 +For further information on the process and further details please refer to
  120 +https://wiki.php.net/vcs/gitworkflow and https://wiki.php.net/vcs/gitfaq
  121 +
  122 +Happy hacking,
  123 +
  124 +PHP Team
146 README.SVN-RULES
... ... @@ -1,146 +0,0 @@
1   -====================
2   - SVN Commit Rules
3   -====================
4   -
5   -This is the first file you should be reading after you get your SVN account.
6   -We'll assume you're basically familiar with SVN, but feel free to post
7   -your questions on the mailing list. Please have a look at
8   -http://svnbook.red-bean.com/ for more detailed information on SVN.
9   -
10   -PHP is developed through the efforts of a large number of people.
11   -Collaboration is a Good Thing(tm), and SVN lets us do this. Thus, following
12   -some basic rules with regards to SVN usage will::
13   -
14   - a. Make everybody happier, especially those responsible for maintaining
15   - the SVN itself.
16   -
17   - b. Keep the changes consistently well documented and easily trackable.
18   -
19   - c. Prevent some of those 'Oops' moments.
20   -
21   - d. Increase the general level of good will on planet Earth.
22   -
23   -Having said that, here are the organizational rules::
24   -
25   - 1. Respect other people working on the project.
26   -
27   - 2. Discuss any significant changes on the list before committing and get
28   - confirmation from the release manager for the given branch.
29   -
30   - 3. Look at EXTENSIONS file to see who is the primary maintainer of
31   - the code you want to contribute to.
32   -
33   - 4. If you "strongly disagree" about something another person did, don't
34   - start fighting publicly - take it up in private email.
35   -
36   - 5. If you don't know how to do something, ask first!
37   -
38   - 6. Test your changes before committing them. We mean it. Really.
39   - To do so use "make test".
40   -
41   - 7. For development use the --enable-maintainer-zts switch to ensure your
42   - code handles TSRM correctly and doesn't break for those who need that.
43   -
44   -Currently we have the following branches in use::
45   -
46   - trunk Will become PHP 6.0. This CVS branch is for active development.
47   -
48   - branches/PHP_5_3 Is used to release the PHP 5.3.x series. It still allows for
49   - larger enhancements.
50   -
51   - branches/PHP_5_2 Is used to release the PHP 5.2.x series. Only bugfixes are permitted
52   - on this branch (Consult the releasemaster prior to commit).
53   -
54   - branches/PHP_5_1 This branch is closed.
55   -
56   - branches/PHP_4_4 This branch is closed.
57   -
58   -The next few rules are more of a technical nature::
59   -
60   - 1. All changes should first go to trunk and then get merged from trunk
61   - (aka MFH'ed) to all other relevant branches.
62   -
63   - 2. DO NOT TOUCH ChangeLog! It is automagically updated from the commit
64   - messages every day. Woe be to those who attempt to mess with it.
65   -
66   - 3. All news updates intended for public viewing, such as new features,
67   - bug fixes, improvements, etc., should go into the NEWS file of the
68   - *first* to be released version with the given change. In other words
69   - any NEWS file change only needs to done in one branch.
70   -
71   - NB! Lines, starting with @ will go automagically into NEWS file, but
72   - this is NOT recommended, though. Please, add news entries directly to
73   - NEWS file and don't forget to keep them adjusted and sorted.
74   -
75   - 4. Do not commit multiple file and dump all messages in one commit. If you
76   - modified several unrelated files, commit each group separately and
77   - provide a nice commit message for each one. See example below.
78   -
79   - 5. Do write your commit message in such a way that it makes sense even
80   - without the corresponding diff. One should be able to look at it, and
81   - immediately know what was modified. Definitely include the function name
82   - in the message as shown below.
83   -
84   - 6. In your commit messages, keep each line shorter than 80 characters. And
85   - try to align your lines vertically, if they wrap. It looks bad otherwise.
86   -
87   - 7. If you modified a function that is callable from PHP, prepend PHP to
88   - the function name as shown below.
89   -
90   -
91   -The format of the commit messages is pretty simple.
92   -
93   -Use a - to start a new item in your commit message.
94   -
95   -If a line begins with #, it is taken to be a comment and will not appear
96   -in the ChangeLog. Everything else goes into the ChangeLog.
97   -
98   -It is important to note that if your comment or news logline spans multiple
99   -lines, you have to put # at the beginning of **every** such line.
100   -
101   -Example. Say you modified two files, datetime.c and string.c. In datetime.c you
102   -added a new format option for the date() function, and in string.c you fixed a
103   -memory leak in php_trim(). Don't commit both of these at once. Commit them
104   -separately and try to make sure your commit messages look something like the
105   -following.
106   -
107   -For datetime.c::
108   -
109   - - Added new 'K' format modifier to date() for printing out number of days
110   - until New Year's Eve.
111   -
112   -For string.c::
113   -
114   - - Fixed a memory leak in php_trim() resulting from improper use of zval_dtor().
115   - #- Man, that thing was leaking all over the place!
116   -
117   -The # lines will be omitted from the ChangeLog automagically.
118   -
119   -Use the [DOC] tag in your log message whenever you feel that your changes
120   -imply a documentation modification. The php-doc team will automatically
121   -get notified about your commit through the php-doc mailing list.
122   -
123   -If you fix some bugs, you should note the bug ID numbers in your
124   -commit message. Bug ID should be prefixed by "#" for easier access to
125   -bug report when developers are browsing CVS via LXR or Bonsai.
126   -
127   -Example::
128   -
129   - Fixed bug #14016 (pgsql notice handler double free crash bug.)
130   -
131   -If you don't see your messages in ChangeLog right away, don't worry!
132   -These files are updated once a day, so your stuff will not show up until
133   -somewhat later.
134   -
135   -When you change the NEWS file for a bug fix, then please keep the bugs
136   -sorted in decreasing order under the fixed version.
137   -
138   -You can use LXR (http://lxr.php.net/) and Bonsai (http://bonsai.php.net/)
139   -to look at PHP SVN repository in various ways.
140   -
141   -To receive daily updates to ChangeLog and NEWS, send an empty message to
142   -php-cvs-daily-subscribe@lists.php.net.
143   -
144   -Happy hacking,
145   -
146   -PHP Team

0 comments on commit e0d5138

Please sign in to comment.
Something went wrong with that request. Please try again.