[Bioperl-l] Re: Towards a 0.7 release

Jason Stajich jason@chg.mc.duke.edu
Fri, 10 Nov 2000 16:01:24 -0500 (EST)

On Fri, 10 Nov 2000, Ewan Birney wrote:

> On Fri, 10 Nov 2000, Hilmar Lapp wrote:
> Thanks Hilmar for the post - for people not in the know, I have been
> hassling Hilmar to lead us towards 0.7 branching for a while - Hilmar has
> finally given in ;)
> Considering hilmar's valiant effort for the 0.6.2 release I feel he is
> ideal to lead us to the 0.7 series...

Here! Here!  Nice work Hilmar.

> One thing to help us here is to have a concerted effort to improve the
> test suite of bioperl. This gives us better automatic backward
> compatibility/stability ...

This a place where those new to bioperl can jump in.  You can learn how to
use a particular module pretty well by trying to write a test suite for
all of its functions.  Many of our existing tests do not test all aspects
of a module, it would be good to really expand this.

> > 
> > Issues/Objectives of the next BioPerl 0.7 release:
> > 1) Timeline: While in principle the final timeline could be extended as far
> > as January, given the new functionality covering technology frequently used
> > by people I think a sooner release is preferable. So, if it should get out
> > of the door by this year, Dec 11th is a reasonable timeline, because
> > anything later is not much different from next year. This would imply a
> > code freeze for the nascent branch on Dec 4th in terms of new code, meaning
> > that once we start to branch the only changes will be bug-fixes. This would
> > give us 4 weeks to implement everything we think is missing, see below.
> Ok. I'm happy with this.
> > 2) Bugs: Ideally, 0.7 starts bug-free. In reality, probably most of us feel
> > unable to provide maintenance for the Blast.pm module, so a lot of those
> > may remain unfixed. As was mentioned earlier, documentation bugs are
> > serious and shall all be fixed.
> I think we need someone committed to lead the documentation effort. 
> **PLEASE** this is where many people who have used bioperl can contribute.
> This will really impress me if someone volunteers to really lead the
> documentation effort as we head up towards the 0.7 branch
>   Don't ask what bioperl can do for you - ask what you can do for Bioperl!

Again, another place where those casual bioperl USERS might do a much
better job than the original developer since they have a better sense of
how to use the module in different ways.

Also a set of simple getting started scripts would be ideal.  

> > 3) Cross-compatibility:
> > Ewan brought to my attention that the divisions of the bio* projects should
> > interoperate smoothly through the BioCORBA layer, and that this needs to be
> > ensured. Given the 0.2.0 BioCORBA proposal, the question now also is
> > whether the 0.7 release shall be compliant with the latest BioCORBA
> > version, and whether it is sensible to believe that this can be
> > accomplished in due time.
> It is more than just the Biocorba stuff. We have 3 major packages
> coordinating with Bioperl
>      - Biocorba (biocorba client/server)
>      - Bioperl-gui 
>      - Ensembl
> My feeling is that these packages need to at least give a "no show
> stopper" ok before we branch to 0.7. I am happy to do this for Ensembl.
> I hope Jason can step up for biocorba and David/Mark for bioperl-gui

I will be happy to manage the biocorba-bioperl effort.  Those interested
in dabbling in biocorba/bioperl code let me know and we can coordinate.

> Biocorba has bigger implications however than the other 2 as for biocorba
> it really has to have a small mismatch with bioperl, meaning generally
> we have to make sure that bioperl adapts to be able to handle biocorba.
> The big thing here is sequence feature/ sequence feature locations along
> with the dreaded (and annoying) fuzziness.. 

Yes, yes.  Lets really try and handle fuzziness somehow.  Handling the
myriad of variations on EMBL and Genbank features is annoying, but make
Bioperl extremely useful, let's try and make it work.

> > 4) Architecture
> > What is the trend we wish codecore to go? Usage of Bio::Root::* modules,
> > suggested StreamIO and NetIO classes. 
> We need to debate these. I want to see Bio::Root::Object die (sorry
> steve!) but I doubt we can do that officially in this release. This is
> open to debate of course.

All new modules that I have written are Bio::Root::RootI dependent.  I 
am fully in support of going this way.  If we feel that is our new
diretcion, someone (me?) can write up a template for how to start a
bioperl module - then we can try and enforce this template on all existing
and new bioperl modules.  A daunting task, perhaps, but by spliting it up
we can do it quickly.

> > 5) Functionality
> > Some modules are pending, which needs to be fixd (e.g. SeqFeatureProducer).
> > Some modules we agreed to modify in order to inherit off a particular base
> > class (e.g., HHMER parser).
> > 
> Indeed. I think we have
>    BPLite upgrade to match Ian's latest release
>    HMMER to come into the new Analysis framework
> ?? other stuff?

I'll help in the finishing off the SeqFeatureProducer, I dropped it this
summer because I wasn't sure what approach was going to be best - parsers
in Bio::Tools::* which implemented an interface, or what.  Hilmar and I
debated this for a while, but the course to follow has since left my
brain...  Would like to see us write this as a proposal so it is clear (at
least for me!).

> > Points 4 and 5 are certainly poorly stated, but it is very late for me, and
> > I tried to finish before sleep takes full control of me.
> > 
> > Please comment, and let us get it off the ground.
> > 
> > 	Hilmar
> > 
> > -- 
> > -----------------------------------------------------------------
> > Hilmar Lapp                                email: hlapp@gmx.net
> > GNF, San Diego, Ca. 92122                  phone: +1 858 812 1757
> > -----------------------------------------------------------------
> > 
> -----------------------------------------------------------------
> Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
> <birney@ebi.ac.uk>. 
> -----------------------------------------------------------------
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l@bioperl.org
> http://bioperl.org/mailman/listinfo/bioperl-l

Jason Stajich
(919)684-1806 (office) 
(919)684-2275 (fax) 
Center for Human Genetics - Duke University Medical Center