[Rd] Contributors on R-Forge

[Matthew Dowle]

"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 :
>> Hi,
>>
>>
>> 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
> committed.
>
> You can give people committer status, but ask them to post their patches
> as issues before committing. This reduces the burden imposed on the
> reviewer/maintainer.
>
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.

Matthew


>
> Regards
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>