[Rd] Contributors on R-Forge
mdowle at mdowle.plus.com
Fri Oct 21 16:12:15 CEST 2011
"Milan Bouchet-Valat" <nalimilan at club.fr> wrote in message
news:1319202026.9174.6.camel at milan...
> Le vendredi 21 octobre 2011 à 13:39 +0100, Charles Roosen a écrit :
>> I've recently taken over maintenance for the "xtable" package, and have
>> set it up on R-Forge. At the moment I'm pondering what the best way is
>> to handle submitted patches. Basically, is it better to:
>> 1) Be non-restrictive regarding committer status, let individuals
>> change the code with minimal pre-commit review, and figure changes can
>> be reviewed before release.
>> 2) Accept patches and basically log them as issues to look at in
>> detail before putting them in.
> I'd say you'd better review patches before they go in, as it would be
> quite ugly to fix things afterwards, right before the release. If a
> patch is buggy, better catch problems early instead of waiting for
> changes to add up: then, it will be harder to find out the origin of the
> bug. It also allows you to spot small issues like styling and
> indentation, that you wouldn't bother to fix once they've been
> You can give people committer status, but ask them to post their patches
> as issues before committing. This reduces the burden imposed on the
My view :
1) Yes, be non-restrictive but impose some ground rules :
i) each commit should pass 'R CMD check'
ii) each new feature or bug fix should have an associated
test added to the test suite (run by R CMD check), and an
item added to NEWS (by the committer).
iii) all developers subscribe to the -commits list and review
each commit in a timely manner when the unified diff arrives
in your inbox. If something is wrong or forgotten, ask the
committer to fix it there and then.
> R-devel at r-project.org mailing list
More information about the R-devel