[Bioc-devel] All Package Maintainers Please README!

[Douglas Bates]

On 10/26/07, Martin Morgan <mtmorgan at fhcrc.org> wrote:
> "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.

A bit off-topic but there is also a program called svn2cl for
producing changelog entries from the svn logs.  I find it very
convenient because it combines information on the revision number, the
files that were modified and the commit message.
>
> > 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
> >>>
> >>> _______________________________________________
> >>> 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}}
> >
> > _______________________________________________
> > Bioc-devel at stat.math.ethz.ch mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> --
> 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
>
> _______________________________________________
> Bioc-devel at stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>