Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Oct 2001 10:03:32 -0700
From:      bmah@FreeBSD.org (Bruce A. Mah)
To:        Ruslan Ermilov <ru@FreeBSD.org>
Cc:        "Bruce A. Mah" <bmah@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/release/doc/en_US.ISO8859-1/relnotes/common new.sgml 
Message-ID:  <200110191703.f9JH3Wd31166@c527597-a.cstvl1.sfba.home.com>
In-Reply-To: <20011019193440.C24666@sunbay.com> 
References:  <200110191632.f9JGWJh20315@freefall.freebsd.org> <20011019193440.C24666@sunbay.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--==_Exmh_-1525047804P
Content-Type: text/plain; charset=us-ascii

If memory serves me right, Ruslan Ermilov wrote:
> Are there any rules you use to decide if a particular change should
> be put here or not?

Not formally, no.  Basically...what's the average user (for some
definition of "average user") likely to want to know?

Observations of my own behavior, subject to change at any point in the 
future:

o New drivers or hardware support always gets mentioned.

o New executables always get mentioned.

o Security advisories always get mentioned.

o New functionality (e.g. features, command-line flags) usually gets
mentioned, if a large number of users would be affected.

o General bugfixes will sometimes get mentioned, if they're major or a
large number of users are affected.

o Imports of contributed software (regardless of where it lives in the
tree) always gets mentioned.

o ports/ changes are never mentioned.  (The one exception so far in the
past year was the CVSup S1G bug.)

o doc/ changes are never mentioned.

o Milestones for large architectural projects get written up if they 
can be expressed concisely.

o I hate saying this, but the easier it is for me to write a release
note, the more likely (and more timely) it is to happen.

	Corollary:  "better" commit messages are more likely to result in
	release note entries, because I don't have to go crawling around
	in src/ or whereever to figure out something.  In the worst case, 
	I'll drop it on the floor.

	Corollary:  If someone takes the time to write up some text 
	about a change they've done, it's more likely to make it to 
	the release notes.

	Corollary:  If someone commits a change to the release notes
	directly (with or without informing me), it's likely to stay 
	there.

	Corollary:  Parts of FreeBSD with which I'm familiar are more 
	likely to get better coverage.

Bruce.

PS.  As a general note to the -committer community at large:  It's
perfectly fine to commit your own release notes entries (as long as you
don't break the release documentation builds, obviously), and I'll quite
happy to provide guidance/reviews on request.




--==_Exmh_-1525047804P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: Exmh version 2.3.1+ 05/14/2001

iD8DBQE70Fzj2MoxcVugUsMRAjhDAKDGqhPFyYLO/CnY/nWX+USY569opQCeMXhz
AISZryyUWByi7YulTKzyQi4=
=7why
-----END PGP SIGNATURE-----

--==_Exmh_-1525047804P--

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110191703.f9JH3Wd31166>