2012-02-16 31 views
15

Có tài nguyên cộng đồng R chuẩn nào để cập nhật các lỗi đã biết hoặc sửa lỗi cho các gói không? Cách tiếp cận hiện tại của tôi là khá thủ công. (NB: Tôi đang hạn chế điều này đối với CRAN - xem Lưu ý 1.)Làm thế nào để bám sát các lỗi đã biết và sửa lỗi trong gói R?

Trường hợp sử dụng của tôi về cơ bản là giám sát lỗi và quản lý cập nhật gói. Tôi đã được trung bình một vài khám phá lỗi mỗi tháng cho một thời gian (mà tôi báo cáo hợp lệ cho các tác giả ;-)). Vì rất nhiều công việc của tôi được thực hiện với các máy ảo, tôi có xu hướng cập nhật các hình ảnh VM khi tôi có một xử lý tốt về trạng thái lỗi cho các gói cần thiết. Khi một loạt các lỗi được sửa, tôi có thể xóa các giải pháp của mình, điều này thật tuyệt vời và tôi cập nhật hình ảnh. Khi tôi phát hiện ra một đợt bùng phát lỗi, tôi không tạo ra một hình ảnh mới.

Dưới đây là những nguồn Tôi hiện đang sử dụng:

  • file NEWS: Nhiều, nhưng không phải tất cả, bao bì có file NEWS. Đây chắc chắn là một nơi hữu ích để bắt đầu.
  • Trang chủ gói: Một số gói không có tệp TIN TỨC trên CRAN, nhưng đăng riêng nhật ký thay đổi trên trang của tác giả.
  • R dự án đã tổ chức mailing list
  • Google Groups đối với các gói
  • thông tin liên lạc cá nhân với các tác giả gói
  • theo dõi Bug đối với các gói (ví dụ như một nhà phát triển có thể sử dụng Bugzilla)

Đó là một điều cần được là người đầu tiên phát hiện ra lỗi (tôi cho rằng các lỗi đó xảy ra với tất cả chúng ta), đó là một lỗi khác để phát hiện ra một lỗi đã được biết đến hoặc, tốt hơn, đã được sửa. Cả hai đều làm chậm mã hóa của riêng tôi, nhưng giám sát lỗi tốt hơn (có lẽ chúng ta cần một gói cdc4R :)) sẽ làm giảm đáng kể tác động. Không có hệ thống cảnh báo cập nhật chuẩn (ví dụ: tiện ích mở rộng cho update.packages() báo cáo về gói nào có thể được cập nhật và liên kết đến thông tin về những gì đã thay đổi), đó là công việc của người dùng để tìm kiếm thông tin này.

Là người dùng như vậy, cố gắng tìm kiếm thông tin này, có một số tài nguyên chuẩn mà tôi đã bỏ qua trong danh sách ở trên không? Ví dụ: có danh sách gửi thư R ở đâu các nhà phát triển thường đăng thay đổi và sửa lỗi của họ không? Hoặc là có một trang web tổng hợp các bài viết, bài kiểm tra bài viết (CRAN bài viết R CMD CHECK đầu ra, có vẻ như), hoặc cung cấp cho một số thông tin phản hồi khác?


Một vài lưu ý bổ sung đối với các nguồn lực khác, vì lợi ích của người khác:

  • Tôi thấy rằng CRANberriesdiff tóm tắt ngắn gọn về các gói, đó là mới mẻ với tôi. (Tôi lấy cảm hứng để xem xét grep cho bug hoặc fix trong đầu ra khác.)
  • bug.report() trong R là cách tốt để gửi thư tới R Core hoặc địa chỉ email của người bảo trì gói.
  • Một số gói thử nghiệm đáng xem xét là: testthat, RUnitsvUnit.
  • "Kiểm tra nhanh" cá nhân của tôi chỉ đơn giản là sử dụng digest để xác minh rằng kết quả phù hợp, mà không phải kiểm tra sự bình đẳng của các đối tượng rất lớn.

Lưu ý 1: Tôi đang gắn thẻ này vì nó không thể quản lý vũ trụ của tất cả gói R. Đối với một tác giả gói riêng lẻ, người ta có thể phân phối gói ở bất cứ nơi nào họ muốn, sử dụng danh sách gửi thư hoặc hệ thống theo dõi lỗi mà họ thích, v.v. Tuy nhiên, đó là ngoài "chủ đạo" cho R. Tôi có phải phát hành gói và cảnh báo người dùng không để thay đổi, lỗi, sửa lỗi, tôi muốn sử dụng CRAN + TIN TỨC + Bugzilla + Google Groups + R-Forge (và/hoặc RForge), v.v ... nhưng có một cơ chế báo cáo chuẩn nào khác bị thiếu trong danh sách này không?

Trong một số ý nghĩa, ghi chú này cũng đáp ứng yêu cầu nếu có cơ chế khuyến khích nhà phát triển sử dụng. Tôi nghi ngờ không có tiêu chuẩn, như các gói của các thành viên R Core dường như làm nhiều điều khác nhau liên quan đến lỗi và báo cáo thay đổi.

Lưu ý 2: Tôi cũng đang thêm (mặc dù điều gì khác có thể là apropos hơn), vì điều này cũng liên quan đến việc quản lý R. Để tái sản xuất, quản trị gói là khá quan trọng; khi có nhiều người dùng hoặc nhiều phần di chuyển hơn, việc lưu ý các lỗi và bản sửa lỗi sẽ trở thành một nhiệm vụ quản trị, cũng như xem xét quan trọng cho sự phát triển phụ thuộc vào các gói bên ngoài. Nếu một thẻ khác, ví dụ: phù hợp hơn, tôi mở để thay đổi.

+1

điều này nên bằng cách nào đó một tính năng của CRAN, phải không? CRAN phải biết về bản cập nhật nên tôi cảm thấy cần có một số kênh RSS cho họ! Đặt yêu cầu tính năng cho CRAN! Hoặc là vấn đề để phân biệt liệu bản cập nhật có sửa lỗi hay không? – TMS

+0

@Tomas Tôi quan tâm đến lỗi; thật dễ dàng để kiểm tra xem các gói đã được cập nhật chưa. Lỗi là một vấn đề khác và cần chú ý: Tôi có thể cập nhật lên phiên bản mới hơn, hoàn nguyên về phiên bản cũ hơn hoặc làm việc xung quanh chúng, nếu chúng tác động đến công việc của tôi. Các thay đổi khác đối với mã, chẳng hạn như thay đổi hiệu suất hoặc giao diện yêu cầu sự chú ý ngay lập tức ít hơn trong một hệ thống đã hoạt động. – Iterator

+0

Tôi không nghĩ rằng bạn đã bỏ lỡ bất cứ điều gì lớn. Tôi sử dụng github cho tất cả các gói của mình, vì vậy các vấn đề của NEWS + github là những nơi tốt nhất để xem. – hadley

Trả lời

3

Không phải là câu trả lời hoàn chỉnh nhưng dưới đây là một số suy nghĩ.

Trong trường hợp data.table, chúng tôi theo dõi lỗi (và yêu cầu tính năng) on R-Forge here. Tôi tưởng tượng bạn có thể truy vấn trình theo dõi của R-Forge (theo chương trình) cho tất cả các gói được lưu trữ ở đó. Để thêm vào danh sách của bạn. Trình theo dõi web đó là nơi bug.report(package="data.table") trỏ tới (không chỉ là địa chỉ email để duy trì).

Ngoài ra, bất kỳ ai cũng có thể đăng ký bất kỳ danh sách gửi thư nào <pkgname>[email protected] để nhận thông báo khác biệt và cam kết hợp nhất (tại thời điểm cam kết) cho từng dự án trên R-Forge. Tuy nhiên, tôi không biết về một danh sách gửi thư chung kéo dài bất kỳ cam kết nào đối với bất kỳ dự án R-Forge nào.

Ở đầu ?data.table có liên kết đến up to the minute NEWS. Đây là cách chúng tôi liên lạc với người dùng trong phiên bản mới nhất (và đang phát triển) nếu họ nâng cấp. Liên kết đó cập nhật trong thời gian thực; nghĩa là "tối đa phút" có nghĩa đen. Nhưng, họ phải kiểm tra ở đó!

+0

Các email cam kết phải được kích hoạt bởi dự án, phải không? Tôi không nghĩ rằng nó là trên cho mỗi dự án R-Forge duy nhất. Nhưng có lẽ điều đó đã thay đổi ... –

+0

@Dirk Tôi nghĩ rằng các quy tắc được tạo theo mặc định nhưng quản trị viên dự án có thể tắt nó đi (có thể là sai). Tôi không nghĩ rằng bất cứ ai được tự động đăng ký với nó, mặc dù, ngay cả admin.Vì vậy, có lẽ đối với các dự án mà không ai đăng ký vào -commits, nó không gửi bất kỳ thông điệp nào, và do đó lưu trữ không tích lũy cho đến lần commit đầu tiên sau lần đăng ký đầu tiên. Chỉ cần đoán thôi. –

+0

Cảm ơn các đề xuất! Sự phát triển của bạn về 'data.table' và quản trị báo cáo và thay đổi rất tuyệt vời và được đánh giá cao. Đó là một trong những gói mà tôi phụ thuộc, cùng với các cơ sở báo cáo và theo dõi bạn sử dụng. Tôi nhận ra rằng tôi không có tài nguyên giống nhau trên các gói khác và tự hỏi làm cách nào tôi có thể giải quyết vấn đề đó. – Iterator

Các vấn đề liên quan