aboutsummaryrefslogtreecommitdiffstats
path: root/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body
diff options
context:
space:
mode:
authorW. Trevor King <wking@drexel.edu>2009-07-21 15:22:09 -0400
committerW. Trevor King <wking@drexel.edu>2009-07-21 15:22:09 -0400
commit9ef8e376212786d8a99cfa19bfcd9c6e70735d0a (patch)
tree50d05dc3394845e1d1fd172be9125102d07ad43e /.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body
parent949b17853e384d4bce85a2ab0b29cf28375465aa (diff)
downloadbugseverywhere-9ef8e376212786d8a99cfa19bfcd9c6e70735d0a.tar.gz
I imported a few threads from the mailing list as wishlist bugs.
12c:uw: Bug aggregation. Multi-repo meta-BE? 529:ow: How should we version BE? 2f0:aw: Static html report generation 22b:aw: Sorting targets chronologically d99:aw: CherryPy interface "Cherry-flavored BE" e08:aw: Interactive email interface
Diffstat (limited to '.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body')
-rw-r--r--.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body58
1 files changed, 58 insertions, 0 deletions
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body
new file mode 100644
index 0000000..a0b6a14
--- /dev/null
+++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/2bb7b4d0-6290-4771-9fff-4aa2e8086b1a/body
@@ -0,0 +1,58 @@
+Chris Ball <cjb@laptop.org> writes:
+
+> Hi,
+>
+> > That's not a changelog, that's a commit log of every source-level
+> > commit made. Far too much detail for a changelog of
+> > *user-visible* changes associated with a release.
+>
+> I think I agree with both of you. :) It seems like it's both true that
+> there's no point in keeping a GNU-style ChangeLog these days
+
+I think I have a better understanding of why this apparent disagreement
+occurred, and it was due to my sloppy use of terms.
+
+Looking into it further, it seems there is a certain expectation (set,
+in part, by the long-standing GNU coding conventions) that a “GNU-style
+ChangeLog” contains not only a particular *format*, but information at
+a particular level of *detail*.
+
+That is, a GNU ChangeLog is intended for the style of work where one
+logs all the changes made to every file in the tree each working day,
+and then makes a new day's entry above that, and so on. This is, of
+course, entirely redundant with a VCS revision history, which makes all
+the commit messages available on request.
+
+So to disambiguate, that's not what I meant. I'm more familiar with a
+less-frequently-updated and less-fine-detail change log; perhaps more
+akin to the GNU-style “NEWS” file.
+
+> and that if we make a release we should write an announce mail that
+> directly mentions new user-visible changes as well as attaching the
+> commit log. That smaller list of highly user-visible changes could
+> live in NEWS, or in the announce mail, or both.
+
+Yes, that's mostly what I meant.
+
+I actually don't think the commit log needs to be part of the release at
+all. It's of interest only to those who want fine-level detail about
+changes to every file, and for that purpose I think read access to the
+VCS is much better. Packaging a static copy of the commit log as plain
+text seems pointless.
+
+Rather, we should treat a user-changes level “NEWS” file (or whatever
+name we choose for it) as part of the documentation, and set the
+expectation among the team that it will be updated for each user-visible
+change being worked on, like any other documentation.
+
+--
+ \ “… Nature … is seen to do all things Herself and through |
+ `\ herself of own accord, rid of all gods.” —Titus Lucretius |
+_o__) Carus, c. 40 BCE |
+Ben Finney
+
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel