zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: zsh-workers@sunsite.dk
Subject: Re: ChangeLog formatting?
Date: Tue, 23 Oct 2001 17:56:08 +0100	[thread overview]
Message-ID: <3BD5A128.5220CDFE@yahoo.co.uk> (raw)
In-Reply-To: <1011023161311.ZM19039@candle.brasslantern.com>

Bart Schaefer wrote:
> 
> Should we agree on some "rules" for ChangeLog entries?

> 
> We're particularly inconsistent about how we credit other contributors (I'm
> guilty of this too).  Examples:
>
>         * 15562, Akinori Musha: 15559, 15563: Completion/BSD/Command/_chflags,

I would vote for this format for credited contributions. By putting the
name before message numbers, it can be inferred that the first message
number was by whomever committed the change without their having to
repeat their own name. First names only should be suffcient for the
usual suspects (as is common at the moment) and e-mail addresses are
perhaps more information than anyone will ever use.

>         * Adapted from Stefan Dalibor, 16043: Src/utils.c: checkrmall()
>         must not print to shout when shout's not valid.

Here, it looks like the contributed change was modified slightly in a
way that is too insignificant to post. So we need a way to cover this.

> With respect to different reasons for different files, most of the time the
> files are still all listed together after the article, and the descriptions
> are all grouped together as well, and it's up to the reader to figure out
> which ones go together.  I only found one previous example of breaking up
> the list of files:

Splitting these as per the example more often is perhaps a good idea
then.

> Finally, as you can see from the above, examples, we're also inconsistent
> about capitalization, whether there is a newline after the colon at the
> end of the list of file names, and at what column the lines should wrap,
> but those are much less significant details.

My votes here are for wrapping so the maximum line is 79 characters. No
newline after the colon unless it could only be followed by about one
word before wrapping at the line end, no initial capitalisation to
avoid the temptation to capitalise the first letter of a function name.
If we don't capitalise, then no final full-stop for consistency with
that. As you say though, these issues are less significant so I don't
care much and will happily defer to anyone else's suggestions.

We could also agree on the format of notes added to cvs - some notes
are preceded by the message number and a colon while others are
followed by the message numbr in brackets.

Oliver


  reply	other threads:[~2001-10-23 16:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-23 16:13 Bart Schaefer
2001-10-23 16:56 ` Oliver Kiddle [this message]
2001-10-23 20:05 ` Adam Spiers
2001-10-23 23:37   ` Wayne Davison
2001-10-24  0:05     ` Bart Schaefer
2001-10-24 14:02       ` Clint Adams
2001-10-25 17:25         ` Adam Spiers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3BD5A128.5220CDFE@yahoo.co.uk \
    --to=okiddle@yahoo.co.uk \
    --cc=zsh-workers@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).