gentoo-alt/trunk/skel.ChangeLog

# ChangeLog for <CATEGORY>/<PACKAGE_NAME>
# Copyright 1999-2004 Gentoo Foundation; Distributed under the GPL v2
# $Header$

*<PACKAGE_NAME>-<PACKAGE_VERSION>-<PACKAGE_RELEASE> (DD MMM YYYY)

  DD MMM YYYY; YOUR_NAME <YOUR_EMAIL> changed_file1, changed_file2 :
  Initial import.  Ebuild submitted by submitter_name <submitter_email>.
  Note that the "changed_file" listing is optional if you are simply bumping
  the rev of the ebuild and are only making changes to the .ebuild file
  itself.  Also note that we now have a single unified paragraph rather than
  having the first line separated from the rest by a newline.  Everything
  should be in one block like this. (note by drobbins, 16 Jul 2002)

  DD MMM YYYY; YOUR_NAME <YOUR_EMAIL> changed_file1, changed_file2: this is
  an earlier ChangeLog entry.
 
-- Explanation of ChangeLog format:

  ***************************************************************************
  THIS IS IMPORTANT: The ChangeLog format is a *chronological* account of all
  changes made to a set of ebuilds. That means that the most recent ChangeLog
  entry *always* goes at the top of the file. More explanation below.
  ***************************************************************************

  ***************************************************************************
  ANOTHER IMPORTANT NOTE: There are some ChangeLogs that don't follow this
  format and organize all changes under the "correct" "*" entry. This is not
  correct. However, rather than making a concerted effort to fix these
  ChangeLogs, we should spend our energy defining a comprehensive and strict
  XML-based ChangeLog format which we then migrate to. But for any entries to
  any ChangeLog that *you* make, please make sure to always add entries to the
  top of the file like a good boy/girl. Even do this if it's clear that you're
  adding an entry to a b0rked ChangeLog.
  ***************************************************************************
  
  This changelog is targeted to users. This means that the comments should be
  well explained and written in clean English.
 
  Every new version or revision of the package should be marked by a '*'
  separator line as above to indicate where in the chronology it was first
  added to our CVS tree. Any changes since the last revision, really _any
  changes at all_ have to be added to the top of the file, underneath the
  initial copyright and cvs header comments, in exactly the same format as this
  comment. If you are modifying older ebuilds, simply note them as changed
  files and add your entry to the top of the ChangeLog. Resist the temptation
  to "organize" your ChangeLog entries by placing them under the "correct" "*"
  entries -- this isn't the purpose of the "*" entries.
  
  This means that you start with header line that has the following format,
  indented two spaces:
  
  DD MMM YYYY; your_name <your_email> changed_file1, changed_file2: Your
  explanation should follow. It should be indented and wrapped at a line width
  of 80 characters.  The changed_files can be omitted if they are obvious; for
  example, if you are only modifying the .ebuild file and committing a new rev
  of a package.  Any details about what exactly changed in the code should be
  added as a message when the changes are committed to cvs, not in this file.

-- A word regarding credit:

  Please add credit information ("ebuild submitted by ...", "patch submitted
  by ...") to the ChangeLog. Do not add this information to the ebuilds
  themselves.

  And remember: Give credit where credit is due. We're all doing this for
  free, so the best we can hope (and expect!) to receive is credit.
1	# ChangeLog for <CATEGORY>/<PACKAGE_NAME>
2	# Copyright 1999-2004 Gentoo Foundation; Distributed under the GPL v2
3	# $Header$
4
5	*<PACKAGE_NAME>-<PACKAGE_VERSION>-<PACKAGE_RELEASE> (DD MMM YYYY)
6
7	DD MMM YYYY; YOUR_NAME <YOUR_EMAIL> changed_file1, changed_file2 :
8	Initial import. Ebuild submitted by submitter_name <submitter_email>.
9	Note that the "changed_file" listing is optional if you are simply bumping
10	the rev of the ebuild and are only making changes to the .ebuild file
11	itself. Also note that we now have a single unified paragraph rather than
12	having the first line separated from the rest by a newline. Everything
13	should be in one block like this. (note by drobbins, 16 Jul 2002)
14
15	DD MMM YYYY; YOUR_NAME <YOUR_EMAIL> changed_file1, changed_file2: this is
16	an earlier ChangeLog entry.
17
18	-- Explanation of ChangeLog format:
19
20	***************************************************************************
21	THIS IS IMPORTANT: The ChangeLog format is a chronological account of all
22	changes made to a set of ebuilds. That means that the most recent ChangeLog
23	entry always goes at the top of the file. More explanation below.
24	***************************************************************************
25
26	***************************************************************************
27	ANOTHER IMPORTANT NOTE: There are some ChangeLogs that don't follow this
28	format and organize all changes under the "correct" "*" entry. This is not
29	correct. However, rather than making a concerted effort to fix these
30	ChangeLogs, we should spend our energy defining a comprehensive and strict
31	XML-based ChangeLog format which we then migrate to. But for any entries to
32	any ChangeLog that you make, please make sure to always add entries to the
33	top of the file like a good boy/girl. Even do this if it's clear that you're
34	adding an entry to a b0rked ChangeLog.
35	***************************************************************************
36
37	This changelog is targeted to users. This means that the comments should be
38	well explained and written in clean English.
39
40	Every new version or revision of the package should be marked by a '*'
41	separator line as above to indicate where in the chronology it was first
42	added to our CVS tree. Any changes since the last revision, really _any
43	changes at all_ have to be added to the top of the file, underneath the
44	initial copyright and cvs header comments, in exactly the same format as this
45	comment. If you are modifying older ebuilds, simply note them as changed
46	files and add your entry to the top of the ChangeLog. Resist the temptation
47	to "organize" your ChangeLog entries by placing them under the "correct" "*"
48	entries -- this isn't the purpose of the "*" entries.
49
50	This means that you start with header line that has the following format,
51	indented two spaces:
52
53	DD MMM YYYY; your_name <your_email> changed_file1, changed_file2: Your
54	explanation should follow. It should be indented and wrapped at a line width
55	of 80 characters. The changed_files can be omitted if they are obvious; for
56	example, if you are only modifying the .ebuild file and committing a new rev
57	of a package. Any details about what exactly changed in the code should be
58	added as a message when the changes are committed to cvs, not in this file.
59
60	-- A word regarding credit:
61
62	Please add credit information ("ebuild submitted by ...", "patch submitted
63	by ...") to the ChangeLog. Do not add this information to the ebuilds
64	themselves.
65
66	And remember: Give credit where credit is due. We're all doing this for
67	free, so the best we can hope (and expect!) to receive is credit.
Name	Value
svn:eol-style	native
svn:keywords	Author Date Id Revision