Dear Dirk,
On Mon, Jun 30, 2014 at 10:18:27AM -0500, Dirk Eddelbuettel wrote:
>
> On 30 June 2014 at 17:04, Andreas Tille wrote:
> | I would be really happy if you would not choose every communication with
> | me as a chance to bring up the same topic. Moreover your claim is - at
> | least currently - not true.
>
> I tried more gentle suggestions in the past, it didn't work. For years.
> And yes, it REALLY annoys me.
Please be assured that I do not work like you are observing just to
annoy you. I also told you that you have perfect means to either
* do a team upload of any of the packages in question
* file a bug report of any of the packages in question
to solve any urgent problem.
> I checked a month or two ago and it was still rather terrible.
I know that you checked since we had some conversation about this in
rstudio WNPP. I told youin this thread[1]: "I also plan such an
overhaul in June to get all the BioConductor packages refreshed."
and so I did (and also the other R packages).
As a personal note: I personally try to respect my fellow DDs and I
really respect your work. It does not help for our cooperation if you
do not take your fellows honest any more only because they do not set
the same priorities in each and every aspect as you are doing.
> | > What we talk about here is marginal.
> |
> | Could you please base this statement on some more information? As far
>
> I did in my previous email. CRAN checks on 8 or 9 systems, incl 2 Debians.
I keep on thinking that there is a difference between testing a source
package on a Debian machine and testing a binary in the chroot it was
built in. You did not answer how the test is done if not even all the
preconditions needed for a test are packaged.
> | I think I have given good reasons that the wheel is not reinvented by
>
> No you didn't. YOu alluded (imprecisely) to some way of testing out of R
> sources. There are three different unit test frameworks in R, plus the
> tests/ directory. Typically, R CMD check covers all of them for you.
> I still recommend you use that. As that is what it is built for.
I know that there are different testing frameworks - I just packaged one
of it (r-cran-testthat) to be able to do the testing. This is exactly
the point I want to make: We need to do the testing on a closed system
with Debian packaged code to be able to guarantee that the user gets a
package which was tested with the code we are delivering.
> Tests may use Depends: and Suggests: from the DESCRIPTION file so just by
> building you are NOT guaranteed testability.
Only if we set Build-Depends properly - that's exactly the point I try
to make.
> But there are options to R CMD check etc pp
IMHO `R CMD check` is orthogonal to this bug report.
> | testing the resulting binaries in the build process. It would be great
> | if you could answer my arguments - perhaps I was missing some points.
> |
> | > If you have spare cycles, keep your packages current. Please.
> |
> | As said above you might like to check the current status of Debian Med
> | and Debian Science R packages. Those that are lagging behind are
> | waiting for preconditions in new queue. Everything else is up to date
> | and featuring autopkgtests where possible.
>
> I would welcome that change (on the currentness) greatly and look forward to
> taking a look. Personally, after how bad they were (using past tense here
> hoping that has changed) I may not be that likely to use your packages ...
I would be really happy if you would stop trying to make this personal.
BTW, I think there is only one single package in the Debian package pool
which is *really* "my" package. I do not want to hide behind those
teams and I really feel responsible for many of the R packages of the
scientific teams. But I do not regard statements like above as very
productive.
> Anyway, useR is about to start so I stop my participation in this non-Bug
> report now.
It is not very nice if users who are reporting bugs get this kind of
de-classification of their opinion. I'm fine if this bug is fixed in a
longer time frame (I actually did not expected a quick fix but rather
some constructive discussion).
Have fun at useR anyway and feel free on concentrating to the conference
Andreas.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617296#91
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
