Gentoo Archives: gentoo-dev

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