Joris:
I'm sorry about your feelings about my thoughts based on Hadley's related
experience.
I feel lucky to be learning from this community. I'm an R user for many
years, but only became a package developer recently and don't have the
background neither the history in the community for putting in
red with Uwe Ligges, but I guess the other CRAN
>>> reviewers weren't aware of this.
>>>
>>> In both cases, replying to the CRAN email and cc'ing Uwe resolved the
>>> issue quickly and without fuss.
>>>
>>>
>>> -Ori
Joris,
I have no dog in this fight, but I think you should cool down a bit. Hadley
explained why he thought these people were students: it’s the adjective
studentische in the job description. I don’t think he meant, or implied,
any disrespect to the individuals concerned. He is entitled to ask in
eplying to the CRAN email and cc'ing Uwe resolved the
issue quickly and without fuss.
-Original Message-
From: R-package-devel On Behalf
Of Mark van der Loo
Sent: Thursday, 16 May 2019 1:50 AM
To: Jennifer Bryan
Cc: R Package Development
Subject: Re: [R-pkg-devel] CRAN student assistants
Cc: R Package Development
Subject: Re: [R-pkg-devel] CRAN student assistants
Thanks for the excellent comparable package, Hong.
Today's rejection of gargle instructs me to use \donttest{} instead of
\dontrun{}. Most of the affected functions create, load, and/or refresh service
account t
On Thu, May 16, 2019 at 4:59 PM Hadley Wickham wrote:
> Hi all,
>
> I am most interested in understanding what level of
> discretion CRAN's "Studentischer administrativer Mitarbeiter" have to
> critique the implementation of R packages
Ing. is the german title for "Engineer". You made her name
o
> Sent: Thursday, 16 May 2019 1:50 AM
> To: Jennifer Bryan
> Cc: R Package Development
> Subject: Re: [R-pkg-devel] CRAN student assistants
>
> For what it's worth,
>
> I recently submitted a new package that was initially refused (with
> comments) by CRAN. I upda
Hi!
Mi humble opinion:
I cannot evaluate the workload for CRAN maintainer, but it don't seem to be
reasonable that students can make objections with packages that "do not
yield R CMD check problems or otherwise violate CRAN policies."
Maybe CRAN maintainer team are giving review tasks for those
Hi all,
The thread seems to have drifted off topic. I really didn't want this
to devolve into a discussion about when cat() or message() is more
appropriate — I have complete faith in Jenny Bryan's ability to
understand technical tradeoffs and pick the most appropriate given the
constraints. I am
rk
van der Loo
Sent: Thursday, 16 May 2019 1:50 AM
To: Jennifer Bryan
Cc: R Package Development
Subject: Re: [R-pkg-devel] CRAN student assistants
For what it's worth,
I recently submitted a new package that was initially refused (with
comments) by CRAN. I updated number of them according
On 15/05/2019 10:40 a.m., Jennifer Bryan wrote:
Hello,
Since this has turned into a worldwide code review, I will briefly address
that, then reiterate the point of the original message.
I am working on an initial release of a package. It reveals information to
a user, sometimes in a print metho
For what it's worth,
I recently submitted a new package that was initially refused (with
comments) by CRAN. I updated number of them accordingly, but there were a
few that with good reasons I could not change. I explained this in the
comments when uploading a new version and it got accepted. So I
Hello,
Since this has turned into a worldwide code review, I will briefly address
that, then reiterate the point of the original message.
I am working on an initial release of a package. It reveals information to
a user, sometimes in a print method-y way, sometimes in more of a verbose /
debuggin
Dialogue is not always getting what you demand in one step. One form dialogue
with CRAN is re-submitting with CRAN-correspondence stating what one wants.
Also, for a lot of applications being able to turn off messages is critical.
> Sorry first sentence should read
>
> I agree that `message(
Sorry first sentence should read
I agree that `message()` is ideally preferred, precisely because
of the reasons Martin stated, it is easily controlled by the user.
On Wed, May 15, 2019 at 9:41 AM Jim Hester wrote:
>
> I agree that `message()` is in an ideally preferred, precisely because
> of t
I agree that `message()` is in an ideally preferred, precisely because
of the reasons Martin stated, it is easily controlled by the user.
Unfortunately, in the real world, the windows R gui console and
RStudio (which copied behavior) color messages, and anything on stderr
in fact, in red, which co
message() / warning() / stop() write to stderr whereas print() / cat() write
(by default) to stdout. Even without being able to suppress messages, it is
well-established practice (the story is that this is the reason why 'stderr'
was introduced into unix,
https://www.jstorimer.com/blogs/working
Dear all,
as a CRAN contributor, I am interested in answers to the questions
Hadley raises.
I very much appreciate the huge amount of work the CRAN team do. I get
the impression that hitherto much of it has been funded by "goodwill".
That's not sustainable and it definitely needs to be staffed
su
I can't speak for Hadley, but my read of his email was that CRAN has
appointed new staff and while extra staff are clearly justified, it
was unclear how they were appointed and whether they had equal
seniority and authority as existing members. Indeed, the fact they use
titles which are clearly jun
Dear Hadley,
a follow up mail: You know who they are. Your organisation has the policy
to add all email correspondence with CRAN to the github repo.
https://github.com/r-lib/gargle/tree/master/cran-correspondence
That's how I now also found out who they are. One is a doctor. She has a
PhD. The m
Dear Hadley,
given you're on the list of R foundation members, I rest assured you have
other channels to ask about the identity of new CRAN staff directly to
those responsible. Their names and paychecks are of no interest to the
general dev world. I can understand CRAN doesn't want to make these n
21 matches
Mail list logo
