Hi, Charles:
On 10/21/2011 7:54 AM, Steve Lianoglou wrote:
Looke like Yihui and I are on the same page.
Just wanted to add another comment with respect to his point here:
I'd encourage you to consider using github as the place for
development, and sync to r-forge so users can install the dev
Looke like Yihui and I are on the same page.
Just wanted to add another comment with respect to his point here:
> 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-fo
Hi,
I know you mentioned you just set this up on r-forge, but I think
using something like github works better in "these types" of
scenarios.
The ability for an external entity to clone a repository, change it,
provide the patch via a "pull request" I think is great.
You (as the project owner) c
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 t
"Milan Bouchet-Valat" wrote in message
news:1319202026.9174.6.camel@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 th
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
