[Bioperl-l] New code

Ewan Birney birney@ebi.ac.uk
Sat, 29 Dec 2001 10:34:09 +0000 (GMT)


On Fri, 28 Dec 2001, Jason Stajich wrote:

> On Fri, 28 Dec 2001, Ewan Birney wrote:
> > Many thanks Steve.
> >
> ditto.
> >
> > Steve has sent a rather more detailed message to me and Jason. We have
> > some unpicking to do here as we now have about 4 different "parsing BLAST"
> > based on three frameworks. Thankfully this is not as bad as it sounds as
> > both Jason and Steve want to move things together into this event based
> > parsing system (SearchIO) keepiing all the goodies from previous systems
> > (eg, Bio::Tools::Blast).
> >
> >
> > I am feverently hoping that Jason can take point in smoothing all this
> > over and figuring out how and where to prune out modules. Jason - are you
> > up for this (...please say yes...)
> >
> 
> What I need to do are things like fold the Bio::Search::HSPI and
> Bio::Search::HSP::HSPI into a single interface - need to agree upon silly
> things like the methods report_type() vs algorithm() which are just
> different names for same things - or just keep both.  Then reimplement
> my parsers (blastxml,fasta) with the new objects.  Not too much work I
> think.

I think as these interfaces have never really been in a stable branch, I
reckon we should just go for one. Mind you, it is cheap to put in the
compatibility mode .... Hmmm... your choice.

> 
> We'll have to decide on naming convention here - Hit vs Subject as we use
> them interchangeably (Steve's stuff uses Hit - but the SimilarityPair and
> BPlite nomeclature was subject).
> 

I prefer Hit much more than Subject.

> I like Steve's idea to have a specific BlastHSP implementation rather than
> trying to make the object generic enough for all types of reports - should
> be able to handle HMMer reports here nicely as well.
> 

Cool

> 
> >
> > I think the right thing to do here is wait for Jason's call on the Search
> > modules and the first round of pruning and then go for a 0.9.3 developer
> > release in earlish Jan (around the 8th say) assumming everything is
> > looking good.
> >
> 
> Seems reasonable.  I will give it a good once through this weekend and see
> what can be done.   This assumes that 0.9.1 has gone out?  and we are
> skipping 0.9.2 ?
> 


My screw up - I thought that we already had done a 0.9.1 and this one was
0.9.2 - so we are skipping 0.9.1 from my perspective. Is this ok?

> >
> >
> > At this point I don't want to hear of any other large additions/changes to
> > the modules - we are officially in cleaning up/sdmoothing mode for the
> > next month. Realistically we are not going to be releasing 1.0 in late Jan
> > - it is going to be late Feb or March, but we need to concentrate on
> > details not big things from here on in...
> >
> 
> I've got Roger looking at implementing DB::GenBank Entrez batch fetch
> based on Lincoln's Boulder::GenBank code - just got to be reimplemented
> with LWP and hooked into the NCBIHelper system.  Hopefully he will have
> time and can get that in - no API changes from this.
> 

Sounds ok.

> >
> >
> > I'd also like the documentation effort ideal to start around 0.9.3 (Peter
> > - are you ready for this - does anyone else want to help here?) with
> > someone ideally doing an audit about where we need update/improve etc
> > documentation. 1.0 is going to need to have good documentation from the
> > start not lagging in a 1.1 release or whatever as I suspect we'll have a
> > whole set of new people poking it when we release 1.0
> >
> 
> Here here!  One thing that would help is a checklist when the audits are
> done - Wiki was a bit of pain for this in the past - perhaps something
> else can be looked at. (webteam how's it going?)
> 

Yup. We need some one to keep us in line. For the people out there who are
not coders but want to help (come on... you know you want to....) we need

  (a) someone to be a majordomo (as in band-leader, not mail list
organiser) for us all, posting/maintaining a checklist and checking things
off. Traditionally I am not so good at this.

   
  (b) Documentation audit. Basically I think every piece of POD needs to
read with fresh eyes and changes made to it appropiately. Ideally this is
someone who can use CVS so that the changes can go straight in there.


  (c) Top level documentation team - the main part of this is Peter's
tutorial but I am sensing we need a NewBie focused area and possibly some
infrastructure area about explaining to hard core coders how to extend
bioperl (basically introducing them to SeqIO, SearchIO and friends)  


> >
> >
> > For the newbies - I will be writting a Bio::Perl module which will give
> > function orientated access to basic bioperl objects to ease the learning
> > curve.
> >
> >
> >
> >
> > But it is looking like a very impressive 1.0 release when it comes!
> >
> 
> Should have a nice feature list to talk about end of Jan even if no
> executeable - really great.
> 

Yup. I will be finnessing this in Tuscon talking about how great this is
etc etc even though we wont have actually got a 1.0 distribution out ;)