[Bioperl-l] Splits again

[Jason Stajich]

Hey guys - I'm wading in a bit late as I haven't had time to keep up  
with whole discussion.

So you are suggesting 800+ individual CPAN modules?  I don't think  
that is a good idea.  Why would you split up Bio::Seq::RichSeq and  
Bio::Seq into two separate packages for example? I think if you  
really want to move away from the monolithic install it has to be  
more logical by function - but I am not that optimistic that this is  
going to actually be easier for people.  Maybe I'm misunderstanding.

What are the arguments for separating things -- to make it so people  
aren't scared by the number of modules so they'll code?  It seems  
like some people just want it to be installed and run scripts - does  
having them install dozens of modules work.  Do we need to consider  
people how much this would suck if someone can't use CPAN or  
Module::Builder to automate dependancy tracking installation?  How  
does it work when modules are deprecated?

I'm not sure I have made up my mind on what I'd like to see, but at  
some point I think we need to get a clearer idea of what audience we  
are trying to serve best.  If want it to be easy to install maybe we  
should invest time into making OSX double-click installers, RPMs, and  
the Windows stuff easily installable.  If we want to serve the  
developers who aren't using SVN so we want to push out releases of  
modules ASAP?  I just am not clear on the motivation for some of the  
proposed changes.

Also - the main point I wanted to make - Can I suggest we spend a  
little time discussing what it will take to get a stable release for  
the current code as it stands (bioperl-live and bioperl-run)?  It  
seems like we really need to do this first so that we have a stable  
release that can be followed by CVS -> SVN migration, then consider  
major changes to the repository structure and release packaging, and  
potential deprecation and incorporation of other modules.


I assume there is no chance that we'd have a 1.6 candidate by BOSC  
next month?

Will it be productive to schedule a fair amount of time at BOSC  
discussing how to partition out the packages into separate sub- 
packages after we've done a successful release rather than trying to  
change things right now? I realize not everyone will be there but  
maybe it will be easier to interact on this then.

I think it will also be time to talk with Lincoln/Scott about how  
Gbrowse is structured and if that is working for them.  There is too  
much code in different places that I think we need to figure out how  
to structure it properly so those packages can be released.  It would  
probably mean moving Bio::Graphics, Bio::DB::GFF and  
Bio::DB::SeqFeature and gff tools for Gbrowse into separate packages  
so they could be released more regularly on par with Gbrowse  
schedules.   Also I think someone needs to figure out Bio::Tools::GFF  
vs Bio::FeatureIO -- what do we want to do?  I don't think we really  
fully support GFF3 that well -- the X2GFF scripts probably need some  
more good testing (where X is BLAST,FASTA,Sim4, GenBank, EMBL,  
etc... ) and or migration to the proper GFF writing.


-jason
On Jun 27, 2007, at 7:43 PM, Sendu Bala wrote:

> Chris Fields wrote:
>> On Jun 27, 2007, at 4:05 PM, Sendu Bala wrote:
>>> But the main problem with this approach is that maintenance, global-
>>> style code improvements and releases become a nightmare. I could,
>>> perhaps, imagine a scenario where the repository stayed as-is (one
>>> monolithic collection), but the dist action of Build.PL could be
>>> altered to generate a release package per module instead of one big
>>> release package of all modules, as is currently the case.
>>>
>>> Is there much value in doing that? Does anyone want me to look into
>>> the feasibility of such a thing?
>>
>> Not for the time being, at least in my opinion.  Too much on our
>> plate at this point with svn migration, test conversion, bugzilla
>> running over (next point of attack!), etc.  Maybe something to think
>> about after, though I like the idea of a few splits to core as Steve
>> suggested (SearchIO, Graphics, some LWP-related DB modules).
> [snip]
>> If a fix needed to be made in one set, make the fix, test against
>> bioperl 'base' as a whole, and release when possible.  No need to
>> wait for a full-fledged 1.5.3 release.
>
> What advantage is there of these defined splits instead of individual
> modules? As I see it you lose some of the potential benefits of  
> breaking
> Bioperl up completely, whilst also suffering the maintenance  
> problems I
> outlined in my objection to Steve's post.
>
> Being able to work on all Bioperl from a single cvs (ne svn) check  
> out/
> archive, whilst distributing it as individual modules on CPAN seems  
> like
> the best of both worlds to me. What am I missing?
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l

--
Jason Stajich
jason at bioperl.org
http://jason.open-bio.org/