[Bioc-devel] All Package Maintainers Please README!

James W. MacDonald jmacdon at med.umich.edu
Fri Oct 26 18:30:20 CEST 2007


That is an interesting thought, although I'm not sure if blosxom can be 
coerced into doing such a thing.

Assuming for a moment that it might be possible, can you give me an 
example of what sort of information you are referring to? I agree that a 
list of files is uninformative unless the reader knows what is in each 
file. OTOH, something like a diff, especially for lots of little 
changes, is IMO very difficult to digest.

As an aside, for someone who is maintaining a single package I think the 
convention is that they just have commit privileges for their package 
alone. However, are they unable to check out other packages and do diffs 
themselves?

I see the changelog as being a simple way to tell others that some 
changes of a certain type have been made, and the interested parties 
could then delve deeper into the subject themselves in whatever manner 
works best for them.

Vincent Carey 525-2265 wrote:
> 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 communi...{{dropped:12}}



More information about the Bioc-devel mailing list