Come tenere il passo dei bug noti e delle correzioni dei bug nei pacchetti R?

Question

Esiste una risorsa di comunità R standard per tenersi aggiornati su bug noti o correzioni di errori per i pacchetti? Il mio attuale approccio è piuttosto manuale. (NB: Sto limitando questo a CRAN - vedi Nota 1.)

Il mio caso d'uso è fondamentalmente la sorveglianza degli errori e la gestione degli aggiornamenti dei pacchetti. Ho fatto una media di un paio di scoperte di bug ogni mese per un po '(che debbo riferire agli autori ;-)). Dato che gran parte del mio lavoro è svolto con macchine virtuali, tendo ad aggiornare le immagini VM quando ho un buon controllo sullo stato dei bug per i pacchetti necessari. Quando un sacco di bug sono corretti, posso rimuovere i miei workaround, che è fantastico, e aggiorno le immagini. Quando scopro un'epidemia di bug, non creo una nuova immagine.

Ecco le fonti Attualmente sto usando:

• file NEWS: Molti, ma non tutti, pacchetti ha dei file NEWS. Questi sono certamente un posto utile per iniziare.
• Pagina iniziale del pacchetto: alcuni pacchetti non hanno un file NEWS su CRAN, ma pubblicano separatamente un registro delle modifiche sul sito dell'autore.
• R Project-hosted mailing list
• Google Gruppi per i pacchetti
• Comunicazione personale con gli autori del pacchetto
• tracciamento bug per i pacchetti (per esempio, uno sviluppatore può utilizzare Bugzilla)

E 'una cosa di essere il primo a scoprire un bug (concedo che gli errori capitino a tutti noi), è un altro a scoprire tardivamente un bug che è già noto o, meglio ancora, già risolto. Entrambi rallentano la mia codifica, ma una migliore sorveglianza degli errori (forse abbiamo bisogno di un pacchetto cdc4R :)) ridurrebbe in modo significativo l'impatto. Senza un sistema di avviso di aggiornamento standard (ad esempio un'estensione a update.packages() che riporta quali pacchetti potrebbero essere aggiornati e collegamenti a informazioni su cosa è cambiato), è compito dell'utente cercare tali informazioni.

Come tale utente, cercando di cercare queste informazioni, c'è qualche risorsa standard che ho trascurato nell'elenco sopra? Ad esempio, c'è una mailing list di R dove è comune per gli sviluppatori pubblicare le loro modifiche e correzioni di bug? O c'è un sito che aggrega questi post, i test di post (sembra CRAN post R CMD CHECK), o che dà qualche altro feedback?

---

Alcune note aggiuntive su altre risorse, per il beneficio degli altri:

• vedo che CRANberries ha un laconico diff sintesi sulle confezioni, che è nuovo per me. (Sono ispirato a considerare un grep per bug o fix nell'output.)
• bug.report() in R è un buon modo per inviare un messaggio a R Core o all'indirizzo di posta elettronica di un manutentore del pacchetto.
• Diversi pacchetti di test da prendere in considerazione sono: testthat, RUnit e svUnit.
• Il mio "test rapido" personale è semplicemente utilizzare digest per verificare che i risultati corrispondano, senza dover verificare l'uguaglianza di oggetti molto grandi.

---

Nota 1: sto codifica questo cran perché è impossibile gestire l'universo di tutte le pacchetti R. Per un singolo autore di pacchetti, si può distribuire un pacchetto ovunque si desidera, utilizzare qualsiasi mailing list o sistema di tracciamento dei bug che gli piace, ecc. Tuttavia, questo è al di fuori del "mainstream" per R. Devo rilasciare un pacchetto e avvisare gli utenti a modifiche, bug, correzioni di bug, vorrei andare con CRAN + NEWS + Bugzilla + Google Gruppi + R-Forge (e/o RForge), ecc., ma c'è un altro meccanismo di segnalazione standard che manca a questo elenco?

In un certo senso, questa nota serve anche a chiedere se esiste un meccanismo che gli sviluppatori sono incoraggiati a utilizzare. Sospetto che non ci sia uno standard, visto che i pacchetti dei membri di R Core sembrano fare molte cose diverse per quanto riguarda i bug e la segnalazione dei cambiamenti.

Nota 2: Sto anche aggiungendo administration (anche se qualcos'altro può essere più a proposito), poiché questo si riferisce anche alla somministrazione di R. Per la riproducibilità, la gestione dei pacchetti è piuttosto importante; quando ci sono più utenti o più pezzi mobili, tenere a mente bug e correzioni diventa un compito amministrativo, oltre a un'importante considerazione per lo sviluppo che dipende dai pacchetti esterni. Se un altro tag, ad es. system-administration è più appropriato, sono aperto a una modifica.

Answer 1

Non una risposta completa, ma qui ci sono alcuni pensieri.

Nel caso di data.table rileviamo bug (e richieste di funzionalità) on R-Forge here. Immagino che potresti interrogare il tracker di R-Forge (programmaticamente) per tutti i pacchetti ospitati lì. Per aggiungere alla tua lista comunque. Quel tracker web è dove punta a (non solo un indirizzo e-mail al manutentore).

Inoltre, chiunque può iscriversi a qualsiasi mailing list <pkgname>-commits@lists.r-forge.r-project.org per ricevere un messaggio di diff e commit unificato (al momento del commit) per ciascun progetto su R-Forge. Non sono a conoscenza di una mailing list generale che includa qualsiasi commit su qualsiasi progetto di R-Forge, comunque.

Nella parte superiore di ?data.table c'è un collegamento a up to the minute NEWS. Questo è il modo in cui comunichiamo agli utenti ciò che è nell'ultima versione (e in fase di sviluppo) se si aggiorna. Quel collegamento si aggiorna in tempo reale; cioè, "fino al minuto" è inteso letteralmente. Ma devono controllare lì!