[Bioperl-l] bioperl-dev or branch?

[Chris Fields]

On May 21, 2009, at 4:00 PM, Hilmar Lapp wrote:

> To quote from the thread:
>
> "The idea behind bioperl-dev, as I understand from Chris, is to  
> provide a sort of sandbox for experimental code. Adventuresome users  
> should feel free to play with the code there, but not expect much in  
> the way of support, bug fixes, and the like. There be dragons there.  
> When a bioperl-dev module graduates to the core, then the usual  
> support mechanisms kick in."
>
> I.e., there is a possibility, but no expectation to graduate to  
> core. I think that's important.
>
> My sense is that we all agree that we don't want to abandon svn  
> branches (or do we?). To I'll state the question again: what  
> disqualifies a development project from going into the main trunk  
> (thanks to Sendu for keeping this on the table), and what  
> disqualifies it from going onto a branch, with the remaining resort  
> being bioperl-dev.

At one point not so long ago, we had a very enlivening discussion on- 
list about splitting off chunks of modules into their own  
subdistributions. Everyone seemed relatively on board for the idea,  
which is somewhat summarized here (bioperl-dev is also mentioned):

http://www.bioperl.org/wiki/Proposed_1.6_core_modules

The key aspect that started this all is to have a lean (read: few  
dependencies, relatively stable) core set of modules.  Other related  
modules which add additional dependencies could be moved into a  
bioperl-tools. And (finally) anything lacking the guarantee of API  
stability would be bioperl-dev.  I think several other alternatives  
came up but these seemed to be the final ones.

So:

core  = minimal functionality
tools = complete functionality (requires core)
dev   = experimental APIs, etc (requires core and possibly tools)

If we claim that bioperl-live is representing 'core', we are going the  
direction of code bloat by dropping all new (possibly untested) code  
there.  However, if we can somehow package up the 'live' modules into  
distinct bundles as delineated above that also solves the issue, so  
any new code can go in.  Depending on which avenue we take, I either  
agree or disagree with Sendu on dropping all new code into bioperl- 
live (like a coding version of Schrödinger's cat).

Anyway, I saw a distinct lack of progress towards any solution, so I  
just took the initiative to set up *SOMETHING* so progress is made,  
one way or the other. If bioperl-dev ends up being a temporary spot in  
the road I don't have a problem with that, just as long as we come to  
some consensus on what to do, how to approach it, and make progress  
towards that goal.

> I'm worried about fragmentation here - historically we've been a  
> crowd that has been rather inviting of new contributions into the  
> main code base and tolerant of those additions needing time to  
> mature, and we have been lazy on committing on behalf of other  
> people (which merging patches, branches, and separate repositories  
> on behalf of someone else is) and hence liberal in giving out commit  
> access, and commit to main trunk access.
>
> 	-hilmar

I'm a big fan of branches (I ran all the feature/annotation refactors  
off a branch).  So I have no problem with anyone wanting to test stuff  
out there, with the idea that stuff be merged back in at some point.

(Aside: do we really need to retain feature branches?  Most projects  
remove them after they are merged back in)

Anyway, I don't have a problem with new code being added in and adding  
new devs. And there isn't anything that prevents any dev from  
committing to any of the other bioperl-* repos AFAIK. But a consensus  
would be nice, and the sooner the better.

chris