[Rd] Contributors on R-Forge

[Yihui Xie]

Hi,

I'd encourage you to consider using github as the place for
development, and sync to r-forge so users can install the devel
version by install.packages(..., repos =
'http://r-forge.r-project.org') and r-forge can also do R CMD
build/check for you once in a while.

The reason to use github is that it makes the development *so* much
more transparent and easier to interact with the person who submitted
you patches. Let me show you by an example:
https://github.com/klutometis/roxygen/pull/16 When I first moved from
roxygen to roxygen2 I found a few issues which are not terribly hard
to fix, so I just forked a version and did the fixes, and sent the
original developers a pull request (a patch). They can review the
patch online, and even comment in *specific* lines of the patch and
tell you where you need to revise and resubmit. It is also very easy
for the original author to accept a patch once it is done. I have
never seen anywhere else we can "discuss" a patch as if we were
sitting together and someone pointed to you this line is good, that
line needs improvement, ...

For the quality of the package regarding the patches, I'd also
recommend the package testthat -- when another person submits a patch
to you, it might be good to ask him/her to submit a corresponding test
case, and you can check if this patch will break other of your tests,
or prevent yourself in the future from breaking this new test. This
can make a developer more confident about the package.

BTW, it is good to know xtable is going to be under maintainence. Thanks!

Regards,
Yihui
--
Yihui Xie <xieyihui at gmail.com>
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA



On Fri, Oct 21, 2011 at 7:39 AM, Charles Roosen
<croosen at mango-solutions.com> wrote:
> 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 welcome feedback from package authors regarding pros and cons, or a
> "third way" that's better that either.  Either privately or to the list.
>
>
>
> Thanks,
>
> Charlie
>
>
>
> Charles Roosen, PhD
>
> Technical Director
>
> Mango Solutions AG
>
>
>
>
>
> T: +41 (0)61 206 92 91
>
> M: +41 (0)79 248 70 71
>
> F: +41 (0) 61 206 92 99
>
>
> www.mango-solutions.com <http://www.mango-solutions.com>
>
>
>
> Mango Solutions AG
>
> Aeschenvorstadt 36
>
> 4051 Basel
>
> Switzerland
>
>
>
>
>
> LEGAL NOTICE
> \ This message is intended for the use of...{{dropped:14}}
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>