[Bioperl-l] 0.7 release: Evaluating every module
Jason Stajich
jason@chg.mc.duke.edu
Wed, 15 Nov 2000 16:14:34 -0500 (EST)
Wiki fixed for now until we get another wiseguy who likes to remove all
the text from the pages... We'll probably need to discuss how to
prevent this in the futyre as the quality of the wiki content grows.
I have created a wiki topic 'BioperlReleases' which can be our central
location for coordinating the releases. Linked from it is the
BioperlRelease0.7 topic which is a table of all the bioperl modules and a
place for putting a mark for each of the required checks before we
release.
I have signed up Ewan for the modules he requested. Everyone is
encouraged to sign up for modules they feel they can look over and certify
as compliant with the soon-to-be-named standards for the 0.7 release. You
probably shouldn't start certifying modules until we have a firmly written
plan for what needs to be done. I would like to see additional tests
written for each routine in the module as much as is humanly possible to
catch any potential bugs BEFORE the release...
It is slightly ugly html code underneath it so be careful when you go to
edit the page in wiki.
Things like SteveC's Blast revamp will likely not be part of the 0.7
release - we want to make sure that all the existing modules in the tree
are as clean and properly tested as possible.
-Jason
On Tue, 14 Nov 2000, Jason Stajich wrote:
> Hilmar - I'm happy to serve as point on this. I'll wiki up a list of all
> the modules and who is responsible for them.
>
> Once we establish our minimal requirements we can have a checklist for
> each module so we can be sure every module has been looked at.
>
> -Jason
>
> On Mon, 13 Nov 2000, Ewan Birney wrote:
>
> > On Mon, 13 Nov 2000, Hilmar Lapp wrote:
> >
> > > Jason Stajich wrote:
> > > >
> > > > I would like to propose that we have a checklist and go through the
> > > > standards for every module. As we establish a minimal documentation,
> > > > perhaps RootI compliance, and standardization of subroutine POD, this will
> > > > give us an opportunity for all the code to get a lookover before we
> > > > certify as an 0.7 release.
> > >
> > > I second this proposal, a minimal review before a release is certainly
> > > beneficial. As always, the point is who's going to do this: as a supporter
> > > I must count me myself in; anyone else willing to help? (Anyone supporting
> > > it will automatically be counted :-)
> > >
> > > Jason, does it make sense if you take over this subject, or shall I
> > > coordinate it?
> >
> > Happy to be considered a supporter, and happy to do my time in reviewing
> > code. However, I don't think we will be able to tease out the Root::Object
> > from the blast code, and we can't remove the code (backward compatibility)
> > even though we have BPLite in.
> >
> > I will sign up for doing Bio::Seq, Bio::PrimarySeq, Bio::SimpleAlign,
> > Bio::LoctableSeq and the Bio::Annotation::* set of modules to make them
> > Bio::Root::Object free...
> >
> >
> > I'd like to hear steve's or peter's (vh) view on this in case we are
> > screwing them - does anyone object to this?
> >
> > >
> > > > Also some modules - the Bio::Search::* specifically have been unfinished
> > > > for quite some time. I've communicated with Aaron and he suggested they
> > > > either be finished or removed from the tree. I think a Bio::SearchIO in
> > > > the AlignIO/SeqIO spirit for processing search results (blast,fasta,HMMER)
> > > > would be interesting, but obviously not contained in this release.
> > > > However, decisions should be made if we are going to continue to include
> > > > incomplete modules in a release.
> > > >
> > >
> > > My vote goes for abandoning incomplete stuff from a release; that's what
> > > the development trunk is for. By incomplete I mean modules that are not yet
> > > usable in a meaningful way. It confuses potential users of the package who
> > > may waste their time in trying to figure out whether that module is able to
> > > solve their problem -- only to find out that it's not working yet.
> > >
> >
> >
> > I agree completely hilmar. Not sure if these should be removed from teh
> > trunk completely, or removed on the branch before the first release off
> > the branch...
> >
> > > Hilmar
> > >
> > > --
> > > -------------------------------------------------------------
> > > Hilmar Lapp email: lapp@gnf.org
> > > GNF, San Diego, Ca. 92121 phone: +1-858-812-1757
> > > -------------------------------------------------------------
> > > _______________________________________________
> > > Bioperl-l mailing list
> > > Bioperl-l@bioperl.org
> > > http://bioperl.org/mailman/listinfo/bioperl-l
> > >
> >
> > -----------------------------------------------------------------
> > Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
> > <birney@ebi.ac.uk>.
> > -----------------------------------------------------------------
> >
> >
>
> Jason Stajich
> jason@chg.mc.duke.edu
> http://galton.mc.duke.edu/~jason/
> (919)684-1806 (office)
> (919)684-2275 (fax)
> Center for Human Genetics - Duke University Medical Center
> http://wwwchg.mc.duke.edu/
>
>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l@bioperl.org
> http://bioperl.org/mailman/listinfo/bioperl-l
>
Jason Stajich
jason@chg.mc.duke.edu
http://galton.mc.duke.edu/~jason/
(919)684-1806 (office)
(919)684-2275 (fax)
Center for Human Genetics - Duke University Medical Center
http://wwwchg.mc.duke.edu/