[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