On 5/25/10 2:56 PM, William A. Stein wrote:
On May 25, 2010, at 12:30 PM, Jason Grout<jason-s...@creativetrax.com> wrote:
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
Interesting. If I remember correctly, you and I had a long discussion about
those patch files, in which I was totally against them, and you argued for
them. I think they are there now mostly because of you. I'm still against
them and consider them a waste of time, just like the log in SPKG.txt. I am
glad we now agree.
Yes. I (and at least one other developer that refused to work on spkgs
while we didn't use the standard "distribute patch files" method) argued
that we should only have patch files, while you and Michael argued that
we should only have the actual patched files. I've learned to deal with
it now, and the three-way merging step makes the patch file largely
unnecessary, though it's still an extra step and hassle to figure out
exactly what file under src/ a patched file in patches/ corresponds to.
If we just distributed patch files, that information would be
contained in the patch, automating yet one more mindless tedious thing
that takes time and resources.
In fact, I believe we (you?) proposed adding a foo.file file as well
that would just contain the file path to the file that foo patched. I
worked up a shell script to automatically apply patched files based on
that, but alas, the foo.file file never caught on...
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.
There is a layer of complexity with either approach. One puts the
instructions next to the file being patched, and one puts them in a separate
file. It's just like putting docs in docstrings versus the Sage Constructions
Guide.
I agree that both solutions require work. The layer of complexity I was
talking about was the needing to open yet more files to make sure that
you covered all of your bases in updating an spkg. It seems much easier
to have all the necessary information in one place (easier to remember,
find, and update).
Thanks,
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
