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.
> 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.
>
> 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
--
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
