[gentoo-commits] repo/gentoo:master commit in: /

[Michael Palimaka]

commit:     0a6238e78c10402e0273f3e154a590a9f558f7a2
Author:     Michael Palimaka <kensington <AT> gentoo <DOT> org>
AuthorDate: Mon Jan 25 12:42:25 2016 +0000
Commit:     Michael Palimaka <kensington <AT> gentoo <DOT> org>
CommitDate: Sun Jan 31 18:47:21 2016 +0000
URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0a6238e7

skel.ChangeLog: remove file

ChangeLog files are no longer used since the git migration.

 skel.ChangeLog | 67 ----------------------------------------------------------
 1 file changed, 67 deletions(-)

diff --git a/skel.ChangeLog b/skel.ChangeLog
deleted file mode 100644
index 10ffc31..0000000
--- a/skel.ChangeLog
+++ /dev/null
@@ -1,67 +0,0 @@
-# ChangeLog for <CATEGORY>/<PACKAGE_NAME>
-# Copyright 1999-2016 Gentoo Foundation; Distributed under the GPL v2
-# $Id$
-
-*<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 Git 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 file 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 Git, 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.