[Bioperl-l] bioperl-dev or branch?

[Chris Fields]

On May 21, 2009, at 11:31 PM, Mark A. Jensen wrote:

>
> ----- Original Message ----- From: "Chris Fields" <cjfields at illinois.edu 
> >
> To: "Hilmar Lapp" <hlapp at gmx.net>
> Cc: "Robert Buels" <rmb32 at cornell.edu>; "BioPerl List" <bioperl-l at lists.open-bio.org 
> >
> Sent: Thursday, May 21, 2009 11:08 PM
> Subject: Re: [Bioperl-l] bioperl-dev or branch?
> ...
>> Mm, yes, see what you're saying, the Bio::Root modules in dev  
>> should  be removed.  Was there a particular reason those were  
>> present, Mark?   Do they contain anything new? I ran a diff on a  
>> few of them and  couldn't find anything.
>
> I think I had a vague idea that the Root modules should exist directly
> in the repository, but that is making less and less sense to me now,
> especially after these discussions. The gross distinction I'm making  
> now
> is that while bioperl-live and bioperl-dev possess parallel  
> organization,
> they are otherwise very different animals: bioperl-live is a unit  
> wherein
> the component modules are (or can be expected to be) completely
> interdependent, while different experiments going on in different
> regions of bioperl-dev don't necessarily have to play at all together.
> (That sounds suspiciously like a bunch of legitimate branches.)
> From this angle, Root shouldn't be there at all, unless it's also on  
> the
> operating table.
>
> There are Root modules involved in building/testing. I thought that
> these at least should be there, but now not so sure. What sense
> does a bioperl-dev build make, since one is probably not interested
> in installing everyone's random experiments at once? Probably
> incorporating the desired code as a layer onto the current install
> is the way to go.

That's sort of the idea.  If you want just the base functionality, get  
core/live. 'tools' is an additional layer, and 'dev' a layer around  
that.

> I get the impression from Rob's insights that more sophistication  
> (on my part,
> definitely) in the use of version control would obviate a lot of our
> consternation. So the question is: what's bioperl-dev got that svn  
> ain't got?
> Maybe the solution here is what you cjf have been suggesting lately,  
> that
> the trunk is your friend, and that frequent and fearless branching 
> +merging
> needs to become part of the Modern BioPerl Way.
>
> [Jason, fellow bioperl-dev user, are you there?]
>
>
> MAJ

Well, for one, ->I don't<- want additional (possibly unmaintainable)  
experimental code arbitrarily dropped into core. See the many rants  
about perl core bloat for similarities.

This is not a new practice; lots of larger software projects have a  
similar core/tools/dev scheme and maintain sep. repos for said  
packages.  If we deem something important enough to go into core  
(read: stable, easy to maintain, necessary for core functionality),  
then it goes in. Additional modules, particularly those with  
additional dependencies, go into 'tools'.  Unstable (in-dev) module go  
into 'dev'.  It's very possible for modules to go from one to the  
other depending on the above criteria; for instance, a 'dev' module  
that stabilizes it's API would go into 'tools' or 'core'.

chris