Guidelines for updating standard packages
Dr. David Kirkby
felt updates to .spkg files were not done sufficiently carefully. Japp agreed
with that.
The developers guide has some guidance on how to update .spkg files
http://www.sagemath.org/doc/developer/patching_spkgs.html
which is well written and clear, but perhaps need expanding. Things that come to
my mind, is the author should check
1) Are there any warnings about depreciated options? If so, you need to
understand why the option was given, why it depreciated, and what you should do
about it.
2) Are there any warnings about unrecognized options to configure scripts?
3) If there are any patches, do they need re-writing? If a source file is
overwritten, are you sure that overwriting it is still appropriate?
4) Does it at build on Linux, OSX and Solaris? (The author must provide evidence
to the reviewer).
Since updating .spkg files often introduces platform-specific problems, I
personally feel an author should check these, though others might argue that is
unreasonable. Personally, if a package is working on all platforms, then if
anyone proposes to update it, they should check it sill builds on those platforms.
5) Are any special build instructions listed in SPKG.txt followed?
6) Read ALL the comments in SPKG.txt, to see what people have changed and why.
Do any of them have implications for the update?
7) Are all the patches applied still necessary? Sometimes bugs may be fixed
upstream, so a patch is not required.
8) Are there any new dependencies? Sometimes new versions of packages require
libraries that older ones did not, or require later versions. If so, does Sage
include those dependencies? Just because your system has the dependency, do not
assume that everyone else will have it.
9) Have you read the release notes for the update? If not, do so, and ensure
there is nothing that will obviously cause a problem in Sage.
10) Have you documented the trac ticket for the update in SPKG.txt? If not, do
so. If a ticket is not open for the update, then create the ticket, and
reference that in SPKG.txt
There's probably others, but there are 10 I can think of.
The update of R, the fallout from which is still not totally resolved, would
have failed 2, 4, 8 and 10.
Does anyone have any comments on those, or additions?
Dave
John H Palmieri
> Hi David,
>
> On Sat, Mar 20, 2010 at 11:46 AM, Dr. David Kirkby
>
> <david.kir...@onetel.net> wrote:
>
> <SNIP>
>
> > Does anyone have any comments on those, or additions?
>
I agree, except for part of #4: "The author must provide evidence to
the reviewer". I think we should trust the authors: if they say that
it builds on Solaris, then we should believe that they have tested
it. They shouldn't need to provide anything except a statement. I
would also say that the reviewer should test it themselves on as many
platforms as they have access to.
By the way, to facilitate testing on Solaris, we should have a recent
binary build available so people can quickly install a copy on t2.math
(for instance) to which they have write access. It would be great if
there were a tar.gz file advertised in the motd on that machine.
--
John
Robert Bradshaw
> On Mar 19, 6:21 pm, Minh Nguyen <nguyenmi...@gmail.com> wrote:
>> Hi David,
>>
>> On Sat, Mar 20, 2010 at 11:46 AM, Dr. David Kirkby
>>
>> <david.kir...@onetel.net> wrote:
>>
>> <SNIP>
>>
>>> Does anyone have any comments on those, or additions?
>>
>> The guidelines you listed above sound reasonable to me.
>
> I agree, except for part of #4: "The author must provide evidence to
> the reviewer". I think we should trust the authors: if they say that
> it builds on Solaris, then we should believe that they have tested
> it. They shouldn't need to provide anything except a statement. I
> would also say that the reviewer should test it themselves on as many
> platforms as they have access to.
Seems reasonable to me. I like the idea of a checklist--not all items
may be relevant for all spkgs, but it'll prevent a lot from falling
between the cracks.
- Robert
Dr. David Kirkby
> On Mar 19, 6:21 pm, Minh Nguyen <nguyenmi...@gmail.com> wrote:
>> Hi David,
>>
>> On Sat, Mar 20, 2010 at 11:46 AM, Dr. David Kirkby
>>
>> <david.kir...@onetel.net> wrote:
>>
>> <SNIP>
>>
>>> Does anyone have any comments on those, or additions?
>> The guidelines you listed above sound reasonable to me.
>
> I agree, except for part of #4: "The author must provide evidence to
> the reviewer". I think we should trust the authors: if they say that
> it builds on Solaris, then we should believe that they have tested
> it. They shouldn't need to provide anything except a statement.
How about then changing that to:
"The author should provide the output of 'uname -a' on all system where they
have checked the updated package?"
That would ensure
* They fully understand this, and the system they are using is what they think
it is [1]. If you remotely log into a machine to test code, you might not
understand exactly what it is, and may be mistaken and believe it is OS X when
it is Linux.
* A record of where tested. This would be particularly useful for Linux, as
the trac ticket would have a record he distribution(s) where they tested.
> I
> would also say that the reviewer should test it themselves on as many
> platforms as they have access to.
Well, if the reviewer has access to 50 systems (not impossible if they are a
system admin), it would be unreasonable to expect them to test on every one!
Ideally, though not practical in all cases, the reviewer should test on systems
different to what the author did. If the Linux system the author tested was
Debian, it would be good if the reviewer(s) could find a non-Debian Linux system
to test on. So how about changing #4 to:
"4) Does it at build on Linux, OSX and Solaris? The author should provide the
output of 'uname -a' on all system where they have checked the updated package
and place that on the trac ticket.
The reviewer(s) should test on at least one Linux, OS X and Solaris system.
Ideally, these systems should be different to those used by the author. In the
case of the Linux system, a different distribution of Linux would be preferable.
However, in some cases the reviewer may have no option but to test on the same
systems as the author, though they should try to test on different systems if
possible."
Does that revision seem reasonable?
> By the way, to facilitate testing on Solaris, we should have a recent
> binary build available so people can quickly install a copy on t2.math
> (for instance) to which they have write access. It would be great if
> there were a tar.gz file advertised in the motd on that machine.
>
> --
> John
Yes. I'll create a binary on 't2' for the current release.
Dave
[1] Many years ago, when computer literacy is less than it is today, I heard of
someone going to a job interview and saying they had developed software on a
"wolf" system. It turns it was a VMS system with the hostname of 'wolf'.
Dr. David Kirkby
> Hi David,
>
> On Sat, Mar 20, 2010 at 11:46 AM, Dr. David Kirkby
>
> <SNIP>
>
>> Does anyone have any comments on those, or additions?
>
> please open a ticket and add those guidelines?
>
I will do, though it would be good if we could get some feedback from others
before I add them. John Palmieri felt #4 needed changing. Hence I suggest that
is changed to
"4) Does it at build on Linux, OSX and Solaris? The author should provide the
output of 'uname -a' on all system where they have checked the updated package
and place that on the trac ticket.
The reviewer(s) should test on at least one Linux, OS X and Solaris system.
Ideally, these systems should be different to those used by the author. In the
case of the Linux system, a different distribution of Linux would be preferable.
However, in some cases the reviewer may have no option but to test on the same
systems as the author, though they should try to test on different systems if
possible."
However, have I overlooked anything?
Dave
Rishikesh
with #1
spkgs are almost always not created by the authors of the package.
Compiler warnings happen in compiling almost every package. It will
be too much expect that people creating spkg eliminate compiler
warnings, even though the package compiles.
with #4
I agree with John Palmieri.
On Mar 19, 8:46 pm, "Dr. David Kirkby" <david.kir...@onetel.net>
wrote:
Robert Bradshaw
> wrote:
>>
>> 1) Are there any warnings about depreciated options? If so, you
>> need to
>> understand why the option was given, why it depreciated, and what
>> you should do
>> about it.
On Mar 20, 2010, at 10:01 AM, Rishikesh wrote:
> I have problem with #1 and #4
>
> with #1
> spkgs are almost always not created by the authors of the package.
> Compiler warnings happen in compiling almost every package. It will
> be too much expect that people creating spkg eliminate compiler
> warnings, even though the package compiles.
I think the point about (1) is that the author should acknowledge
warnings, and with some justification of why they're a non-issue.
Often it could be just a simple as pointing out that there aren't any
*new* warnings (though ideally we will eventually get the upstream
code cleaned).
- Robert
David Kirkby
> I have problem with #1 and #4
>
> with #1
> spkgs are almost always not created by the authors of the package.
> Compiler warnings happen in compiling almost every package. It will
> be too much expect that people creating spkg eliminate compiler
> warnings, even though the package compiles.
I was not saying they should elimiminate compiler warnings. In fact,
no mention was made of a compiler. Neither did I use the word
eliminate.
What I object to is when people update .spkg files, and ignore the
fact configure scripts say options are unreconised.
I dont't think it unreasonable people look at any warnings and ensure
things are no worst than they were, which is what is happening.
>
> with #4
> I agree with John Palmieri.
I revised #4. Were the revisions OK ?
Dave