Gentoo Archives: gentoo-dev

From: gokturk@××××××××××.edu
To: devmanual@g.o
Cc: gentoo-dev@l.g.o
Subject: [gentoo-dev] [PATCH v3 17/21] ebuild-writing/misc-files: remove ChangeLog section #485314
Date: Thu, 04 Feb 2016 01:06:35
Message-Id: 1454547469-22487-18-git-send-email-gokturk@binghamton.edu
In Reply to: [gentoo-dev] [PATCH v3 00/21] devmanual: update the docs for post git-migration by gokturk@binghamton.edu
1 From: Michael Orlitzky <mjo@g.o>
2
3 The ChangeLog section under misc-files is misleading now that our main
4 repository has been switched to git (and we no longer have
5 ChangeLogs). Remove the ebuild-writing/misc-files/changelog page.
6
7 Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=485314
8 ---
9 ebuild-writing/misc-files/changelog/text.xml | 111 ---------------------------
10 ebuild-writing/misc-files/text.xml | 1 -
11 2 files changed, 112 deletions(-)
12 delete mode 100644 ebuild-writing/misc-files/changelog/text.xml
13
14 diff --git a/ebuild-writing/misc-files/changelog/text.xml b/ebuild-writing/misc-files/changelog/text.xml
15 deleted file mode 100644
16 index ff68e11..0000000
17 --- a/ebuild-writing/misc-files/changelog/text.xml
18 +++ /dev/null
19 @@ -1,111 +0,0 @@
20 -<?xml version="1.0"?>
21 -<guide self="ebuild-writing/misc-files/changelog/">
22 -<chapter>
23 -<title>ChangeLog</title>
24 -
25 -<body>
26 -<p>
27 -The <c>ChangeLog</c> must be updated with each commit. The
28 -<uri link="::tools-reference/echangelog/">echangelog tool</uri> should be used to create <c>ChangeLog</c> entries;
29 -the format of a <c>ChangeLog</c> is now defined as "whatever
30 -<c>echangelog</c> creates".
31 -</p>
32 -
33 -<p>
34 -You should include references to any relevant bugs. The standard
35 -format for doing this is via the phrase <c>bug #20600</c> — this
36 -format (with the hash sign included) is recognised via
37 -<uri link="https://packages.gentoo.org">packages.gentoo.org</uri> and
38 -similar tools. When including user-submitted ebuilds or patches, you
39 -should credit the user with their full name and email address (or
40 -whatever they use to identify themselves on bugzilla <d/> some users
41 -prefer to be known only by a nickname).
42 -</p>
43 -
44 -<p>
45 -If you are changing keywords, make sure you clearly state what
46 -keywords you add or remove. "Marked stable" is a nuisance for
47 -architecture teams, even if there was only one keyword in the ebuild
48 -at the time. "Stable on all archs" isn't generally any better (and
49 -should you really be stabling on all archs?) — do you mean "all", or
50 -"all the ones that are currently keyworded"? A list like "x86 sparc
51 -mips" is much more useful.
52 -</p>
53 -
54 -<p>
55 -A typical <c>ChangeLog</c> snippet might look like the following:
56 -</p>
57 -
58 -<pre>
59 - *vim-6.3.068 (25 Mar 2005)
60 -
61 - 25 Mar 2005; Ciaran McCreesh &lt;ciaranm@g.o&gt; +vim-6.3.068.ebuild:
62 - New release. Fixes bug #79981, bug #81289, bug #83383, bug #83416, bug
63 - #83565, bug #85758, upstream patches up to 6.3.068.
64 -
65 - 22 Mar 2005; Aron Griffis &lt;agriffis@g.o&gt; vim-6.3-r4.ebuild:
66 - Stable on alpha
67 -</pre>
68 -
69 -<note>
70 -If a <c>ChangeLog</c> file is not present in your current working directory,
71 -then you should write a <c>ChangeLog</c> entry in the parent's directory
72 -<c>ChangeLog</c> file.
73 -</note>
74 -
75 -<section>
76 -<title>Writing correct ChangeLog messages</title>
77 -<body>
78 -<note>
79 -It is <b>very</b> important that your <c>cvs commit</c> messages are
80 -also informative to aid the QA team or architecture teams as well as
81 -other developers if they are trying to troubleshoot issues which are
82 -known to not have occured in previous versions of ebuilds, for
83 -example. If your ChangeLog message is concise there is usually nothing
84 -wrong with using it as the <c>cvs commit</c> message.
85 -</note>
86 -
87 -<p>
88 -Your message should explain what specifically you changed and, if
89 -relevant, why. You don't need to write an essay or even a complete
90 -sentence (<c>ChangeLog</c> messages, however, are required to be in
91 -'proper' English so no <c>fixed that bug kthx Bob</c> messages —
92 -please do use punctuation), so long as it is easily understandable and
93 -(preferably) greppable. Bad and good examples, all of which are based
94 -upon real messages:
95 -</p>
96 -
97 -<ul>
98 - <li><b>BAD:</b> Changed keywords</li>
99 - <li><e>GOOD:</e> Added ~x86 keyword</li>
100 -</ul>
101 -
102 -<ul>
103 - <li><b>BAD:</b> Stable</li>
104 - <li><e>GOOD:</e> Stable on x86, sparc, mips</li>
105 -</ul>
106 -
107 -<ul>
108 - <li><b>BAD:</b> Fix stuff</li>
109 - <li><e>GOOD:</e> Fix USE=foo logic error</li>
110 -</ul>
111 -
112 -<ul>
113 - <li><b>BAD:</b> .</li>
114 - <li><e>GOOD:</e> Purge old ebuilds</li>
115 -</ul>
116 -
117 -<ul>
118 - <li>
119 - <b>BAD:</b> Who the fuck reads this anyway? (<b>Editor's note</b>:
120 - No, seriously, this is a genuine example. Do <e>not</e> do
121 - this...)
122 - </li>
123 - <li><e>GOOD:</e> Version bump to 0.5.1.</li>
124 -</ul>
125 -
126 -</body>
127 -</section>
128 -</body>
129 -</chapter>
130 -</guide>
131 diff --git a/ebuild-writing/misc-files/text.xml b/ebuild-writing/misc-files/text.xml
132 index 31f1421..416070b 100644
133 --- a/ebuild-writing/misc-files/text.xml
134 +++ b/ebuild-writing/misc-files/text.xml
135 @@ -18,6 +18,5 @@ This section contains some notes on various miscellaneous files.
136 </chapter>
137
138 <include href="metadata/"/>
139 -<include href="changelog/"/>
140 <include href="patches/"/>
141 </guide>
142 --
143 2.4.10