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}}
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. Regards
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 >
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) can also comment on the pull request (in general, or on a line by line basis), allowing it to be refined "online." You can then easily pull in the code change to your repo if you deem it to be up to snuff. This way, people can quite actively take part in your project without being "full fledged committers." When someone crosses your "threshold of trust" ... say you you know/believe that heir code changes are inline w/ your vision and your standards (or whatever your line might be), you can also easily give them full commit access to your project so you don't have to do the pull request/review dance, etc. You of course lose r-forge's cross platform building ability, but you may get the same by taking advantage of git's ability to "talk to" subversion repos and push your git repo to the r-forge's subversion repo when you are ready to submit to CRAN and take advantage of r-forge's automated building and submission mojo. My 2 cents, -steve -- Steve Lianoglou Graduate Student: Computational Systems Biology ?| Memorial Sloan-Kettering Cancer Center ?| Weill Medical College of Cornell University Contact Info: http://cbio.mskcc.org/~lianos/contact