r22 - 2015-12-01 - 07:20:11 - HarlanStennYou are here: NTP >  Dev Web > ReleaseIssues > ReleaseSteps > ChangeLogMaintenance
NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p13 was released on 07 March 2019. It addresses 1 medium-severity security issue in ntpd, and provides 17 non-security bugfixes and 1 other improvements over 4.2.8p12.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

ChangeLog Maintenance

ChangeLog in -dev

If a change is being applied to both -stable and -dev, only add the ChangeLog entry to -stable, as it will get pulled in to -dev from -stable.

Otherwise, add new entries to the appropriate locations in the top-section of the list.


ChangeLog in -stable

Add new entries to the appropriate location of the top part of the list, just after the initial --- and blank line. In other words, the file should look like this:

 ---
 (empty line)
 * [Sec NNN] from smaller to larger numbers
 * CID NNN from smaller to larger numbers - Coverity IDs
 * [Bug NNN] from smaller to larger numbers
 * oldest other entry
 * ...
 * newest other entry
 (empty line) [optional]
 ---

When rolling a new release, the "release" line at the top:

   * (version) YYYY/MM/DD Released by Name <email>

is automatically prepended to the ChangeLog file by the snapshot process.

(The idea for the "date" was suggested independently by both SteveKostecke and, much later, MartinBurnicki.)

ChangeLog Format

The Release Announcement Generator currently supports the following ChangeLog entries:

  * [Sec NNN] a security-related bugfix
  * [Bug NNN] a change which fixes a bug
  * a change added by the development process

Multi-line ChangeLog entries are properly supported.

Other type of (currently unsupported) entries which may be useful include:

  * [Dev NNN] a change which fixes a bug triggered by the development process
  * [Bug NNN - Backward Incompatible] a backward incompatible bugfix
  * [Backward Incompatible] a backward incompatible change added by
     the development process
  * [Deprecated] a change that removes something we have deprecated


I was chatting with Steve and noted that many of the bugs we fix in -dev were bugs that were introduced in -dev and there may be value in distinguishing these from bugs that were discovered in a -stable release.

There will be times when we think we have a [Dev NNN] bugfix and discover it is really a [Bug NNN] issue. When this happens we should watch what happens in the generated message script, as it would probably make a change to a pre-existing entry, which seems to mess up the script.

What about a deprecation that is backward-incompatible?

-- HarlanStenn - ?? ??? ????



Improving the ChangeLog format

When pulling from -stable to -dev how should we get the ChangeLogTag copied from "below the line" to the head of the list? And just because I think it's a good idea to get that information up top doesn't mean that others agree.

The first -dev roll after a major release of -stable does not need to duplicate the ChangeLogTag.

-- HarlanStenn - 17 Aug 2008

We've started to address this by adding lines like:

* Include (4.2.6p1-RC3) - [Bug 1450] Option to exclude warnings not
  unconditionally defined on Windows.

to the -dev ChangeLog file. These break Steve's current parser, and Steve suggests we use something like:

* [Bug 1450] from (4.2.6p1-RC3): Option to exclude warnings not
  unconditionally defined on Windows.

instead.

-- HarlanStenn - 2010-05-05

Harlan's second choice looks cleaner to me because it keeps all [Bug NNN], and other tags, tags at the beginning of the line.

-- SteveKostecke - 2010-05-05

I'm now looking at:

* [Bug 1450] (from 4.2.6p1-RC3): Option to exclude warnings not
  unconditionally defined on Windows.

or

* [Bug 1450] from 4.2.6p1-RC3: Option to exclude warnings not
  unconditionally defined on Windows.

-- HarlanStenn - 2010-05-05

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r22 < r21 < r20 < r19 < r18 | More topic actions
 
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback