On May 25, 2010, at 11:50 AM, William Stein wrote:
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.
I actually think that this will make it less likely to get looked at
and appropriately cleaned up when versions are bumped. When I'd go to
SPKG.txt to update the version information, I would see "Version
x.y.z, with these patches: ..." and if there are notes about stuff
being fixed upstream, I'd take care of it then, rather than having to
look at each patch/about file individually.
- Robert
--
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
