On May 25, 2010, at 1:11 PM, Jason Grout wrote:
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...
One difficulty is that there are some (if I remember) patches that are
only done to some systems, but not others. I too would find it easier
if the /patches directory were actual patches that were applied to /
src automatically, but that's not a big sticking point for me. Was the
problem that then patch became a dependancy?
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).
+1, especially for your example of "applied upstream, not needed after
version Z."
- 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
