On 5/25/10 2:01 PM, Robert Bradshaw wrote:
On May 25, 2010, at 11:50 AM, William Stein wrote:
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.
+1 to Robert's comments. Already, I don't ever make or use foo.patch
files anymore because they are completely redundant and one more
easily-forgotten step to make (they should be totally automated if they
are required). If we added foo.why files (I think 'why' is a nicer
extension :), that would just add a layer of complexity onto the
updating process. So +1 to having all of the necessary
instructions/metadata for updating an spkg right in the SPKG.txt file.
Jason
--
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
