Movatterモバイル変換

187 captures

20 Jan 2012 - 04 Oct 2025

Oct	NOV	Dec
	11
2019	2020	2021

success

fail

About this capture

COLLECTED BY

Organization:Archive Team

Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.

History is littered with hundreds of conflicts over the future of a community, group, location or business that were "resolved" when one of the parties stepped ahead and destroyed what was there. With the original point of contention destroyed, the debates would fall to the wayside. Archive Team believes that by duplicated condemned data, the conversation and debate can continue, as well as the richness and insight gained by keeping the materials. Our projects have ranged in size from a single volunteer downloading the data to a small-but-critical site, to over 100 volunteers stepping forward to acquire terabytes of user-created data to save for future generations.

The main site for Archive Team is atarchiveteam.org and contains up to the date information on various projects, manifestos, plans and walkthroughs.

This collection contains the output of many Archive Team projects, both ongoing and completed. Thanks to the generous providing of disk space by the Internet Archive, multi-terabyte datasets can be made available, as well as in use by theWayback Machine, providing a path back to lost websites and work.

Our collection has grown to the point of having sub-collections for the type of data we acquire. If you are seeking to browse the contents of these collections, the Wayback Machine is the best first stop. Otherwise, you are free to dig into the stacks to see what you may find.

The Archive Team Panic Downloads are full pulldowns of currently extant websites, meant to serve as emergency backups for needed sites that are in danger of closing, or which will be missed dearly if suddenly lost due to hard drive crashes or server failures.

Collection:Archive Team: URLs

TIMESTAMPS

CRAN Repository Policy

Top

Preamble

This document describes the policies in place for theR package repository hosted by theComprehensive R Archive Network. Inwhat follows, thisCRANpackage repository will be referred to as “CRAN”.

CRAN is maintained by the efforts of volunteers (the “CRAN team”) andthe resources of theR Foundation and the employers of those volunteers(WU Wien, TU Dortmund, U Oxford, U Auckland). Having a packagedistributed by CRAN is subject to a set of policies, and submitting apackage (including an update) to CRAN indicates agreement to thesepolicies.

CRAN hosts packages of publication quality and is not a development platform. A package’s contribution has to be non-trivial.

Distributing code or documentation is subject to legal requirements,and CRAN operates in many jurisdictions. One of the aims of thesepolicies is to ensure that the distributors meet their legalobligations of diligence without excessive work.

The time of the volunteers is CRAN’s most precious resource, and theyreserve the right to remove or modify packages on CRAN without noticeor explanation (although notification will usually be given).

All correspondence with CRAN must be sent toCRAN-submissions@R-project.org (for submissions) orCRAN@R-project.org (for published packages)and not to members of the team, in plain text ASCII and not HTML.

Source packages

• The ownership of copyright and intellectual property rights of allcomponents of the package must be clear and unambiguous (including fromthe authors specification in theDESCRIPTION file). Where codeis copied (or derived) from the work of others (including from Ritself), care must be taken that any copyright/license statements arepreserved and authorship is not misrepresented.

  Preferably, an ‘Authors@R’ field would be used with ‘ctb’roles for the authors of such code. Alternatively, the ‘Author’field should list these authors as contributors.

  Where copyrights are held by an entity other than the package authors,this should preferably be indicated via ‘cph’ roles in the‘Authors@R’ field, or using a ‘Copyright’ field (if necessaryreferring to aninst/COPYRIGHTS file).

  Trademarks must be respected.

• The package’sDESCRIPTION file must show both the name and emailaddress of a single designated maintainer (a person, not a mailinglist). That contact address must be kept up to date, and be usable forinformation mailed by the CRAN team without any form of filtering,confirmation …

  The maintainer warrants that (s)he is acting on behalf of all creditedauthors and has their agreement to use their material in the way it isincluded in the package (or if this is not possible, warrants that it isused in accordance with the license granted by the original author).

  AdditionalDESCRIPTION fields could be used for providing emailaddresses for contacting the package authors/developers (e.g.,‘Contact’), or a URL for submitting bug reports (e.g.,‘BugReports’).

  Citations in the ‘Description’ field of theDESCRIPTION fileshould be in author-year style, followed by a DOI or ISBN for publishedmaterials, or a URL otherwise. Preferably, the year and identifierwould be enclosed, respectively, in parentheses and angle brackets.

• Source packages may not contain any form of binary executable code.
• Source packages under an Open Source license must provide source orsomething which can easily be converted back to source (e.g.,.rda files) for all components of the package (including forexample PDF documentation, configure files produced byautoconf). For Java.class and.jar files, thesources should be in a top-leveljava directory in the sourcepackage (or that directory should explain how they can be obtained).

  Such packages are not permitted to require (e.g., by specifying in‘Depends’, ‘Imports’ or ‘LinkingTo’ fields) directly orindirectly a package or external software which restricts users orusage.

  The package’s license must give the right for CRAN to distribute thepackage in perpetuity. Any change to a package’s license must behighlighted when an update is submitted (for there have been instancesof an undocumented license change removing even the right of CRAN todistribute the package).

  Packages with licenses not listed athttps://svn.r-project.org/R/trunk/share/licenses/license.db willgenerally not be accepted.

• Package authors should make all reasonable efforts to providecross-platform portable code. Packages will not normally be acceptedthat do not run on at least two of the major R platforms. Cases forWindows-only packages will be considered, but CRAN may not be the mostappropriate place to host them.
• Packages should be named in a way that does not conflict (irrespectiveof case) with any current or past CRAN package (theArchive area can beconsulted), nor any currentBioconductor package. Package maintainers give the right to use thatpackage name to CRAN when they submit, so the CRAN team may orphan apackage and allow another maintainer to take it over.

  When a new maintainer wishes to take over a package, this should beaccompanied by the written agreement of the previous maintainer(unless the package has been formally orphaned).

• Packages on which a CRAN package depends should be available from amainstream repository: if any mentioned in ‘Suggests’ or‘Enhances’ fields are not from such a repository, where to obtainthem at a repository should be specified in an‘Additional_repositories’ field of theDESCRIPTION file (asa comma-separated list of repository URLs) or for other means of access,described in the ‘Description’ field.

  A package listed in ‘Suggests’ or ‘Enhances’ should be usedconditionally in examples or tests if it cannot straightforwardly beinstalled on the major R platforms. (‘Writing R Extensions’ recommendsthat they arealways used conditionally.)

  Orphaned CRAN packages should not be strict requirements (in the‘Depends’, ‘Imports’ or ‘LinkingTo’ fields, includingindirectly). They are allowed in ‘Suggests’ if used conditionally,although this is discouraged.

• CRAN versions of packages should work with the current CRAN andBioconductor releases of packages they depend on and not anticipate norrecommend development versions of such packages (or themselves) on otherrepositories.
• Packages will not normally be removed from CRAN: however, they maybe archived, including at the maintainer’s request.

  Packages for whichR CMD check gives an ‘ERROR’ when anew Rx.y.0 version is released will be archived (or inexceptional circumstances updated by the CRAN team) unless themaintainer has set a firm deadline for an upcoming update (and keeps toit).

  Maintainers will be asked to update packages which show any warnings orsignificant notes, especially at around the time of a newx.y.0release. Packages which are not updated are liable to be archived.

• Packages should be of the minimum necessary size. Reasonablecompression should be used for data (not just.rda files) and PDFdocumentation: CRAN will if necessary pass the latter throughqpdf.

  As a general rule, neither data nor documentation should exceed 5MB(which covers several books). A CRAN package is not an appropriateway to distribute course notes, and authors will be asked to trimtheir documentation to a maximum of 5MB.

  Where a large amount of data is required (even after compression),consideration should be given to a separate data-only package whichcan be updated only rarely (since older versions of packages arearchived in perpetuity).

  Similar considerations apply to other forms of “data”, e.g.,.jar files.

• Checking the package should take as little CPU time as possible, as theCRAN check farm is a very limited resource and there are thousands ofpackages. Long-running tests and vignette code can be made optional forchecking, but do ensure that the checks that are left do exercise allthe features of the package.

  If running a package uses multiple threads/cores it must never use morethan two simultaneously: the check farm is a shared resource and willtypically be running many checks simultaneously.

  Examples should run for no more than a few seconds each: they areintended to exemplify to the would-be user how to use the functions inthe package.

• Packages which use Internet resources should fail gracefully with aninformative message if the resource is not available or has changed (andnot give a check warning nor error).
• The code and examples provided in a package should never do anythingwhich might be regarded as malicious or anti-social. The following areillustrative examples from past experience.
  • - Compiled code should never terminate the R process within which it isrunning. Thus C/C++ calls toassert/abort/exit/std::terminate, Fortrancalls toSTOP and so on must be avoided. Nor may R code callq().
  • - A package must not tamper with the code already loaded into R: anyattempt to change code in the standard and recommended packages whichship with R is prohibited. Altering the namespace of another packageshould only be done with the agreement of the maintainer of thatpackage.
  • - Packages should not write in the user’s home filespace (includingclipboards), nor anywhere else on the file system apart from the Rsession’s temporary directory (or during installation in the locationpointed to byTMPDIR: and such usage should be cleaned up).Installing into the system’s R installation (e.g., scripts to itsbin directory) is not allowed.

    Limited exceptions may be allowed in interactive sessions if thepackage obtains confirmation from the user.

    For R version 4.0 or later (hence a version dependency is required oronly conditional use is possible), packages may store user-specificdata, configuration and cache files in their respective user directoriesobtained fromtools::R_user_dir(), provided that by default sizesare kept as small as possible and the contents are actively managed(including removing outdated material).

  • - Packages should not modify the global environment (user’s workspace).
  • - Packages should not start external software (such as PDF viewers orbrowsers) during examples or tests unless that specific instance ofthe software is explicitly closed afterwards.
  • - Packages should not send information about the R session to themaintainer’s or third-party sites without obtaining confirmation fromthe user.
  • - Packages must not disable the stack-checking mechanism in the R processinto which they are loaded.
  • -CRAN packages should use only the public API. Hence theyshould not use entry points not declared as API in installed headers nor.Internal() nor.Call() etc calls to base packages. Also,::: should not be used to access undocumented/internal objects inbase packages (nor should other means of access be employed). Suchusages can cause packages to break at any time, even in patched versionsof R.
  • - Packages should not attempt to disable compiler diagnostics, nor toremove other diagnostic information such as symbols in shared objects.
  • - Security provisions must not be cicrumvented, for example by notverifying SSL certificates.
• Changes toCRAN packages causing significant disruption toother packages must be agreed with theCRAN maintainers wellin advance of any publicity. Introduction of packages providingback-compatibility versions of already available packages is notallowed.
• Downloads of additional software or data as part of package installationor startup should only usesecure download mechanisms (e.g.,‘https’ or ‘ftps’). For downloads of more than a few MB,ensure that a sufficiently large timeout is set.

Binary packages

Policies for when a (Windows or macOS) binary package will be distributed:

• all its package dependencies on CRAN are available for that platform.Dependencies from other repositories will be installed at CRAN’sdiscretion.
• any external software needed can easily be installed on the buildmachine for all the sub-architectures: here “easily” includes notdepending on specific versions, nor should the installed binary dependon specific versions.
• it passesR CMD check without error for all the availablesub-architectures, or at CRAN’s discretion, for the most importantsub-architecture(s).

Binary packages are not accepted from maintainers: CRAN will only hostbinary packages prepared by those responsible for the binary areas.Their packages are made automatically by batch jobs and can take a dayor two to appear on the CRAN master site (maybe longer to reach CRANmirrors).

Binary packages are built for the current version of R: they may also bebuilt for the last version in the previous series (e.g. R 3.1.3 when R3.2.x is current) or for R-devel.

Questions about binary packages should be addressed to those responsiblefor building them: Simon Urbanek (macOS) and Uwe Ligges (Windows); emailaddresses ‘First.Lastname@R-project.org’.

Submission

When submitting a package to CRAN you should use the submission form athttps://CRAN.R-project.org/submit.html (and not send an email).You will be sent a confirmation email which needs to be accepted.

You can check that the submission was received bylooking atftp://CRAN.R-project.org/incoming/. Submissiondifficulties (such as non-receipt of the confirmation email) can bediscussed withcran-sysadmin@R-project.org.

In more detail:

• Uploads must be source tarballs created byR CMD build andfollowing thePACKAGE_VERSION.tar.gz naming scheme.This should be done with current R-patched or the current release of R.
• Please ensure thatR CMD check --as-cran has been runonthe tarball to be uploaded before submission. This should be done withthe current version of R-devel (or if that is not possible and explainedin the submission, current R-patched or the current release of R.)For new submissions in particular, please take care to include aninformativeDescription field. Seesubmission_checklist.html for details.

  In principle, packages must passR CMD check without warnings orsignificant notes to be admitted to the mainCRAN packagearea. If there are warnings or notes you cannot eliminate (for examplebecause you believe them to be spurious) send an explanatory note aspart of your covering email, or as a comment on the submission form.

  For interpretation of the URL checks, seeURL_checks.html.

• For a package update, please check that any packages depending on thisone still passR CMD check: it is especially expected that youwill have checked your own packages. Reverse dependencies canconveniently be checked usingtools::check_packages_in_dir(reverse= list()), and changes in check status subsequently be analyzed usingtools::check_packages_in_dir_changes(). A listing of the reversedependencies of the current version can be found on the CRAN web pagefor the package, or be obtained viatools::package_dependencies(reverse = TRUE).If possible, check reverse strong dependencies, reverse suggests and therecursive strong dependencies of these (bytools::package_dependencies(reverse = TRUE, which = "most", recursive = "strong")).
• If for some reason the submission has to be made by someone else (forexample, a co-author) this needs to be explained, and the designatedmaintainer will need to confirm the submission.
• Explain any change in the maintainer’s email address and if possiblesend confirmation from the previous address (by a separate email toCRAN-submissions@R-project.org) or explain why it is not possible.

  If the package needs special treatment (for example if vignettes canonly be run or re-built on the maintainer’s machine or take a very longtime), say so on the submission form.

• Do not email the package itself.
• Once uploaded, no further submissions of that package should be madewhilst the uploaded version is pending processing (which may take afew days) and you have not received a reply from a CRAN maintainer.
• Submitting updates should be done responsibly and with respect for thevolunteers’ time. Once a package is established (which may take severalrounds), “no more than every 1–2 months” seems appropriate.

  Authors can avoid a lot of the all too frequent rounds of updates bychecking carefully for themselves. It should be normal for thosewithout Windows machines of their own to use thewinbuilder service tocheck a package before submission. There is a lot of helpful advice onwriting portable packages in“Writing R Extensions”.

  Before submitting a package update, consult the CRAN check page at‘https://CRAN.R-project.org/web/checks/check_results_NAME.html’,substituting NAME by the name of your package. In particular, wait forthat page to be fully updated after publication of a version (which cantake at least 48 hours) before submitting any corrections.

• If an update will change the package’s API and hence affect packagesdepending on it, it is expected that you will contact the maintainers ofaffected packages and suggest changes, and give them time (at least 2weeks, ideally more) to prepareupdates before submitting your updated package. Do mention inthe submission email which packages are affected and that theirmaintainers have been informed.In order to derive the reverse dependencies of a package including the addresses of maintainers who have to be notified upon changes, the functionreverse_dependencies_with_maintainers is available from the developer website.

Re-submission

Re-submission is done in the same way as submission, using the ‘Optionalcomment’ field on the webform (and not a separate email) to explain howthe feedback on previous submission(s) has been addressed.

Updates to previously-published packages must have an increased version.Increasing the version number at each submission reducesconfusion so is preferred even when a previous submission was notaccepted.

For packages which have been archived since February 2018, a snapshot ofthe CRAN results page at the time of archival will be available underhttps://cran-archive.r-project.org/web/checks/. (Note that onlya few of the links from the snapshot will work: normally those to listed‘Alternative issues’ will.)