[Bioc-devel] Invitation to the bioC developers Meeting in Sea ttle Mon 15 Aug

I'd be happy to follow your suggestions on how to make the package fit more
with affy-type packages (obvious things is creating subsettabble
exprset-like object, possibly methods) for the next release. anything else
that you have in mind? are you suggesting combining three packages? i am
open to this but it would obviously depend on the other authors.

jane


######################################################
Jane Fridlyand
Assistant Professor of Epidemiology and Biostatistics
Center for Bioinformatics and Molecular Biostatistics
UCSF Comprehensive Cancer Center

Office: 2340 Sutter str., N224, SF, CA 94114

Tel: 415-476-0168
Fax: 415-502-3179

######################################################


-----Original Message-----
From: bioc-devel-bounces at stat.math.ethz.ch
[mailto:bioc-devel-bounces at stat.math.ethz.ch] On Behalf Of Jeff Gentry
Sent: Friday, August 05, 2005 11:26 AM
To: bioc-devel at stat.math.ethz.ch
Subject: Re: [Bioc-devel] Invitation to the bioC developers Meeting in
Seattle Mon 15 Aug



On Fri, 5 Aug 2005, Furge, Kyle wrote:

aCGH, DNAcopy, GLAD all use different, internally defined formats for
data storage. In addition, feature annotations are stored in separate
formats rather then annotation environments. Currently, the convert
package does not handle the aCGH, DNAcopy, or GLAD data or annotation
formats. I do not want to speak for the original author or the authors
of these packages, but in this example, it is worth requiring coerce
methods for these (and other) formats into exprSets/annotation
environments at the package acceptance stage?

IIRC, the convert package showed up chronologically before the three
packages that you mentioned - which would explain why it does not handle the
other three.  At the same time it demonstrates the problem of keeping
packages up to date with the state of the art in other packages as well.  I
know I'm guilty of this myself but often package authors/maintainers are not
aware of changes in other packages which are relevant to their own, and this
can be a problem.

In a case like the one you describe, where you've personally identified a
situation that seems like it would make sense to update one (or
more) packages, IMO the thing to do is at the very least to contact the
appropriate maintainers and raise this issue - or even better to develop the
appropriate code/patches to those maintainers.