[Rcpp-devel] On mailing list defaults, and suggested patch submission

[Dominick Samperi]

On Thu, Aug 19, 2010 at 7:54 AM, Dirk Eddelbuettel <edd at debian.org> wrote:

>
> This list runs with standard defaults of Mailman, a popular choice for
> running mailing list, as set up by R-Forge.
>
> In particular, message limits are 40kb. Larger messages are held and then
> create admin work. Yesterday, an attempt to send a 90kb message got
> rejected,
> and I as list owner got the bounce.  The message (according to its body)
> claimed to contain "patches" to source code in Rcpp, yet it looked like it
> contained full copies of the files.
>

It appears that the post got through in spite of the "rejection"?

At any rate, I tried to submit these changes three times, first a list
of changes spelled out so that Rcpp would compile using MSVC.
Then as a private correspondence to Romain who said he would
ignore the submission because it was not posted to the list. And
finally as a post to this list, which resulted in my contributions
being rejected.

These changes consist of just a few small changes to existing
code (all ifdef-ed _MSC_VER so they have no impact on CRAN
builds), and three new files. Obviously I cannot generate context
diffs for new files, and the trivial changes to existing files can
be found by grep-ing for _MSC_VER.

Dominick


> Just like any other open source project, we prefer _patches_ (and see [1]
> if
> you are unclear as to what these are -- they are not _modified copies_)
> rather than copies. If you want us to consider your work, the onus is on
> you
> to demonstrate a) what goal the change is meant to achieve and b) to
> clearly
> delineate what changes are to be made.  Patches do the latter, whereas
> copies
> don't. Additional info on the motivation for the patch (clearer code,
> better
> performance, more foo, ...) also helps.
>
> I would suggest a single patch set (ie output from diff possibly pertaining
> to several files but one "logical" chunk) per email message so that the
> patch
> can be reviewed here.  The patch should preferably be against the current
> SVN
> trunk as we as Rcpp authors tend not to work in branches.  We also tend not
> to set, but commit logs clearly identify which revisions correspond to the
> actual tar ball releases.
>
> Thanks, Dirk
>
>
> [1] http://en.wikipedia.org/wiki/Patch_(Unix)<http://en.wikipedia.org/wiki/Patch_%28Unix%29>
>
> --
> Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
> _______________________________________________
> Rcpp-devel mailing list
> Rcpp-devel at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20100819/ba533c1d/attachment.htm>