2007/12/31, mabshoff <[EMAIL PROTECTED]>: > == Dependencies == > > * gmp > * pari > * NTL >
I feel like this is too much information required for an spkg. I think that only the name, upstream contact and maintainers fields should be required to distribute one. The changelog could be inferred from the hg changelog, the distribution field does not seem to be of any value to me as a user. > * How do we keep SPKG.txt and the wiki page in sync? In an ideal world > we would just copy over the updated SPKG.txt into the wiki and be done > with it. But people will edit the wiki page, i.e. to add contact info > or correct issues. One way would be for the maintainers to subscribe > to the pages of the spkgs they handle and sync it manually. Since the > wiki preserves all edits and offers an interface to diff this should > be relatively easy. That's a great solution. didier > > > > == Distribution == > > > > > === Padus === > > > * Contact: Ismail D�nmez > > > * EMail: [EMAIL PROTECTED] > > > * Website: N/A > > > > > == Changelog == > > > > > === eclib-20071231 (John Cremona) === > > > > > * renamed to eclib > > > * allows elliptic curves as input with rational (as opposed to just > > > integer) coefficients. > > > > > === cremona-20071219.p1 (Michael Abshoff) === > > > > > * patch to fix "Internal error: can't free this _ntl_gbigint" (John > > > Cremona) > > > > > === cremona-20071219.p0 (John Cremona) === > > > > > * fix main Makefile mismerge (Michael Abshoff) > > > * add missing export to g0n/Makefile (John Cremona) > > > * fix permission issue (Michael Abshoff) > > > > > === cremona-20071219 (John Cremona) === > > > > > * update to latest source > > > * fix mwrank error on non-minimal curves (#1233) > > > > > === cremona-20071124.p4 (Michael Abshoff) === > > > > > * apply John Cremoan's second patch for #1403 > > > * delete $SAGE_LOCAL/include/mwrank (#1410) > > > * strip the mwrank binaries and link dynamically (#1410) > > > * delete $SAGE_LOCAL/lib/libmwrank.[so|dylib] (#1410) > > > > > === cremona-20071124.p3 (Michael Abshoff) === > > > > > * apply John Cremoan's patch for #1403 > > > * fix #1256, i.e. remove the now obsolete mwrank.spkg > > > > > === previous versions === > > > > > * lost to history > > > [end example] > > > > > I pasted the verbatim text file intohttp://wiki.sagemath.org/spkg/eclib > > > > > Is there anything missing? Should anything be removed? > > > > > But now there are a couple issues we need to resolve: > > > > > * How do we keep SPKG.txt and the wiki page in sync? In an ideal world > > > we would just copy over the updated SPKG.txt into the wiki and be done > > > with it. But people will edit the wiki page, i.e. to add contact info > > > or correct issues. One way would be for the maintainers to subscribe > > > to the pages of the spkgs they handle and sync it manually. Since the > > > wiki preserves all edits and offers an interface to diff this should > > > be relatively easy. > > > > > * We currently have two couple pages in the wiki that list spkgs: > > > > > http://wiki.sagemath.org/standard_packages_available_for_SAGE > > > http://wiki.sagemath.org/Sage_Spkg_Tracking > > > > > I think both should be merged into one page while preserving the info > > > from both pages. "standard_packages_available_for_SAGE" is slightly > > > older than "Sage_Spkg_Tracking", but I llike the format of > > > "Sage_Spkg_Tracking" better. It also has all current components > > > listed. > > > > > * We would potentially have two wiki pages for each spkg. Take for > > > example Givaro. We have a page at > > > > > http://wiki.sagemath.org/Givaro > > > > > That page lists some examples and compares the performance of GF(2^8) > > > to Magma. That information shouldn't be in SPKG.txt and the example > > > section could potentially be expanded. > > > > > The not yet existing page at > > > > > http://wiki.sagemath.org/spkg/Givaro > > > > > on the other hand would then contain a much more technical changelog. > > > > > I think that we also should merge both pages for each spkg into some > > > part of the manual. It is possible to export wiki pages to latex which > > > in turn then can be stuck into some part like the developer's manual. > > > We should do that via some script so that prior to a release somebody > > > can execute that script. If there is the need to do something manual > > > it won't happen. > > > > > Thought? Ideas? > > > > > Cheers, > > > > > Michael > > > > -- > > John Cremona > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
