[Bioc-devel] All Package Maintainers Please README!

"James W. MacDonald" <jmacdon at med.umich.edu> writes:

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.

At this level it sounds like the interested party is another
developer. svn log -v PKG gives file names. svn diff -r123:127 PKG
gives a diff between stated revisions.

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?

All developers have read access to the entire repository.  Anonymous
has read access to the Rpacks directory of all devel and release
branches. Maybe the wiki could embed te appropriate code for the diff
/ log.

Martin

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

The information transmitted in this electronic communi...{{dropped:12}}

--
Martin Morgan
Computational Biology Shared Resource Director
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M2 B169
Phone: (206) 667-2793