On 10/16/2013 06:36 AM, Andreas Tille wrote:
Hi Martin,
On Wed, Oct 16, 2013 at 06:02:03AM -0700, Martin Morgan wrote:
For precomputed_results above, it looks like these could be
generated by a script, but the specific results depend on a web
service query and the web service changes from time to time. So the
script will become out-of-date, creating data that are no longer
consistent with the illustrative puruposes of the vignette. Also,
the time cost of generating data is not consistent with our
(nightly) build process; we will not generate this data on the fly,
and it would be a mistake for your release process to generate data
different from the data used in our release.
Defintely. The only thing our ftpmaster needs is this kind of
explanation (hopefully).
These (expense of
computation, consistency of external data sources) are typical
reasons.
When the 'affy' maintainer recieves one of these emails, and the
email mentions three data sets, and the three data sets are
documented in the man page as data sets from an experiment (e.g.,
?SpikeIn), what is one supposed to do?
Sorry, I just missed this part of the documentation, my fault.
Or rather, why is he being
contacted in the first place?
That's simple: He is listed on the affy homepage
http://bioconductor.org/packages/release/bioc/html/affy.html
Probably I meant this in a rhetorical way. I mean, "why does the maintainer need
to be contacted about a documented data set?" and you've answered that.
as maintainer and this is what I take over into the according Debian
package metainformation field (in debian/copyright). I have to admit
that I'm personally totally unconnected to BioConductor and have only a
very rough understanding of R. The problem is that in the Debian Med
team some people started to package some BioConductor modules and these
people now vanished from the team or are overworked. My goal is to
keep on their work for our users and namely cummerbund needs some
update with several new preconditions. So I tried to dive into
BioConductor internals and I'm very sorry if I did not yet found all
details how this project is organised
In short: Should I generally override the contact e-mail for
any BioConductor part by
Upstream-Contact: BioConductor Maintainer <maintai...@bioconductor.org>
independently what might be written on the according homepage?
Package maintainers are the ones in a position to decide what to do.
But if you are going to contact package maintainers generally (all 749 packages?
data annotation and experiment data packages [which are more-or-less entirely
binary objects!] too?) then I'd like to bring this up on the Bioconductor devel
mailing list so that package maintainers have a fair chance of knowing what to
expect.
From a non-technical perspective: (1) It's presumptuous to suggest
that the data files are not important for user documentation; if
they where not important why would the author have gone to the
trouble to include them in the first place?
It seems BioConductor is quite good organised but trust me in my 15
years experience of Debian package building that I found lots of files
in upstream sources which are not (any more) needed or not important
enough to keep them inside while an online download would be perfectly
sufficient. Just guessing from this experience I was just suggesting a
possible solution. I hoped to get some helping point for the decision
which was obviously not the case.
(2) If you are going to
contact our maintainers, then please let me know about the extent of
the contact and the intention; I would rather have a discussion on
our developer mailing list than have each maintainer wondering how
to react.
I'll respect this in the future. The intention is simply letting the
package pass ftpmasters criterion - the extent of the contact is hardly
to estimate in advance.
Thanks again for your patience
Andreas.
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org