[Bioperl-l] bioperl-dev or branch?

[Chris Fields]

On May 21, 2009, at 8:51 PM, Mark A. Jensen wrote:

> H-
> ----- Original Message ----- From: "Hilmar Lapp" <hlapp at gmx.net>
> To: "Robert Buels" <rmb32 at cornell.edu>; "Chris Fields" <cjfields at illinois.edu 
> >
> Cc: "BioPerl List" <bioperl-l at lists.open-bio.org>
> Sent: Thursday, May 21, 2009 9:33 PM
> Subject: Re: [Bioperl-l] bioperl-dev or branch?
>
> ...
>
>> That sounds all good to me, except that bioperl-dev has Bio/Root/*  
>> replicated. It should not, right? If we want to introduce  
>> experimental changes to Bio/Root modules, they should go into a  
>> bioperl-live  branch, right? (Otherwise I'm confused what a bioperl- 
>> live branch is  for.)
>
> Well, this is what I'm wondering. For Chase's project, e.g., there  
> may be
> mods that need to take place (or be tried out, and possibly  
> discarded later,
> which is key) in the core modules, to interface the new stuff with  
> the core.

That should probably happen in bioperl-live, then (or a branch  
thereof).  Don't be afraid to branch off bioperl-live if needed to do  
the work.  If it passes tests and looks good we merge it back to core  
trunk.

> So experiments may occasionally depend on (possibly radical) changes  
> to
> the core--nasty for folks (I expect they are many) that update on  
> the core
> regularly and expect changes there to be incremental fixes and/or  
> new and
> relatively well-tested functionality. So I do conceive of bioperl- 
> dev (rightly
> or wrongly) as a parallel branch of bioperl-live, but not a temporary
> "feature" branch as such. It can and prob should be pretty persistent.
> But read on...
>>
>> So in this picture Chase's project would go into bioperl-dev, main   
>> trunk. Users would obtain it by downloading bioperl-dev from svn or  
>> as  package and simply install on top of a Bioperl-core package,  
>> without  fear of clobbering stable modules that came with Bioperl- 
>> core. Right?
>
> This is the way I'd love it to work, modulo the exptl core changes  
> mentioned
> above. My own tendency in development is to make stuff as separable as
> possible (by specifically overriding core methods in 'Helper'  
> modules, for example),
> and if this were part of the bioperl-dev rules of engagement (i.e.,  
> no core modules,
> only overrides), then users could count on the behavior you  
> describe. Mirroring
> the existing core paths is also key for this expectation.

I think mirroring the paths is feasible, but not copying the module's  
name directly.  So you could have a Bio::Root::Moose, but not a  
Bio::Root::Root.

>> If that's the idea it makes a lot of sense to me and seems sane.   
>> Conversely, using bioperl-dev as another way to branch bioperl- 
>> core  modules doesn't, though I may be missing something.
>
> That's the idea in my own private Idaho, here in Georgia.

Same here (from somewhere in corn country).

>> (I hope I'm making sense. Please do say if I'm not ...)
>>
> Me too X 2.
> MAJ

chris