On Tue, May 25, 2010 at 11:36 AM, Robert Bradshaw <rober...@math.washington.edu> wrote: > On May 25, 2010, at 11:26 AM, Jason Grout wrote: > >> On 5/25/10 12:41 PM, Robert Bradshaw wrote: >>> >>> Hi all, >>> >>> I just had a new spkg (rightly) rejected because it didn't have a >>> changelog entry in SPKG.txt , as specified by [1], Does anyone know why >>> are we manually keeping a text changelog when the files under our >>> control are already under revision control? >>> >> >> +1 to just making the commit messages more descriptive, as well as >> insisting that things like: >> >> Applying a patch; this patch should be removed when this package is >> updated because the patch has been applied upstream >> >> are documented in the SPKG.txt. > > > This information is very useful, and probably better not in a changelog, > where it will scroll off the bottom and be forgotten. I'd be up for a > requirement that every patch we make should be listed in SPKG.txt, with a > bit of explanation of why (and, when, if ever, it will become unnecessary), > right next to the version information. That'd be helpful.
Having info about patches is a good idea. I'm definitely not convinced SPKG.txt is the right place for it. I would install propose something *like* for every patch foo, having a file foo.wtf (or something) in patches/ that explains the patch. E.g., $ cd patches $ ls foo foo.patch foo.wtf The file foo.wtf would document why foo is done. Doing things like this will greatly increase the chances that docs are updated when they should be. This is similar to having docstrings in functions, instead of some other distant place. William -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
