[Bioc-devel] All Package Maintainers Please README!
this is interesting. it should provoke better changelog comments. but the comments are less interesting in the absence of data on what files were actually changed. and of course the filenames are not necessarily that informative either. would it be possible to put in links to some data on the actual code changes? you would not want them on the front page, but associated with each comment. my sense is that the changelog comments are not a great vehicle for conveying what is going on. after all, one can be prompted for just one comment related to a large number of changes, and details may be missed. but the actual physical events on code could -- if appropriately accessible, and i do not know if the blosxom can do this without substantial effort -- be much more informative.
On Fri, 26 Oct 2007, James W. MacDonald wrote:
Robert recently suggested that I make a stab at a blog-based changelog rather than the current monthly postings, sort of similar to what Duncan Murdoch has done with the R NEWS and windows CHANGELOG. The biggest difference between what is done for R and what I will be doing for BioC is this; R-core does a really good job of writing explanatory notes describing what the change was, and what it means for the end user. On the other hand, the commit messages that people use range from the ridiculous to the sublime. Since I will no longer be parsing the commit messages by hand, I will not be able to remove the more useless messages that people tend to use, and these things will go straight to the changelog for all to see. So, first thing; if you don't want your section of the changelog to be populated with things like 'WTF was I thinking?!@!?@!?' or 'Oops', or the venerable 'commit' or better yet, the ever popular ' ', you will want to actually use a commit message that means something with respect to the commit you just made. Now I know some of the commit messages are not intended for public consumption, so there is a way out. If you prepend your commit message with INTERNAL, then it will be scrubbed. Or at least I think it will ;-D. I'm using Python for the first time to do the parsing, so I am sure there are bugs aplenty. Note that this INTERNAL thing is _by line_, so if you do something like: INTERNAL This is a commit message nobody should ever see. But they can see this one. Then the second part of the message _should_ get through. Note that you need to use INTERNAL exactly, as it is always possible that someone might use Internal at the beginning of a commit message that they want published, so I am not doing any case-changing on the test for this string. The changelog as it currently exists (with just one day of changes so far) can be viewed here: http://fgc.lsi.umich.edu/cgi-bin/blosxom.cgi Please take a look and send me any suggestions. Best, Jim -- James W. MacDonald, M.S. Biostatistician Affymetrix and cDNA Microarray Core University of Michigan Cancer Center 1500 E. Medical Center Drive 7410 CCGC Ann Arbor MI 48109 734-647-5623
_______________________________________________ Bioc-devel at stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
The information transmitted in this electronic communica...{{dropped:2}}