287d845699
git-svn-id: https://svn.disconnected-by-peer.at/svn/linamh/trunk/linamh@707 6952d904-891a-0410-993b-d76249ca496b
68 lines
3.6 KiB
Plaintext
68 lines
3.6 KiB
Plaintext
# ChangeLog for <CATEGORY>/<PACKAGE_NAME>
|
|
# Copyright 1999-2009 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.
|