[Bioperl-l] bioperl-dev or branch? : redux

[Chris Fields]

On Jun 17, 2009, at 11:47 AM, Mark A. Jensen wrote:

> Hi All,
> I thought I'd revisit this thread, since in the last couple weeks,
> have used both techniques (bioperl-dev and branch from trunk) to
> produce completed projects. My thoughts:
>
> Using bioperl-dev was very nice for creating Bio::Search::Tiling, a
> new addition to the core api. There was no pressure to conform to the
> existing api there. In particular, there was no implicit insistence to
> make things work through Bio::Search::Utils, and I was free to factor
> it out. The Tiling api was definitely unstable until the end, when it
> was ported to the core. As I made regular reports to bioperl-l,
> everything was transparent and up front, and I received excellent
> suggestions there (as usual).
> For Bio::Restriction, using the branch was just as natural. Here, the
> existing structure was well established, and all the work needed to
> happen beneath the api. All old t/Restriction tests needed to pass,
> and additional ones created for the new functionality. So here, using
> bioperl-dev wasn't natural, even though some "experiments" needed to
> be tried (some succeeded and some failed, as you can see in the
> commentary at Bug #2855). Even though the new code turned out to
> require substantial effort, the effort was required to fix a true bug
> in the working core, and any fixes needed to work transparently with
> respect to the users for whom this bug had not been an issue. Using
> the branch made it relatively easy to merge quickly back into the core
> when done, and there is a certain psychological pressure too provided
> by an open branch which is helpful.
>
> Hilmar raised the very good point in the previous discussion that
> (essentially) bioperl-dev shouldn't become a sandbox with lots of
> unfinished code scraps and derelict stuff that doesn't work. My view
> is bioperl-dev will become a sandbox only if we treat it like
> one. I've filled out the Bioperl-dev page on the wiki
> (http://www.bioperl.org/wiki/Bioperl-dev) with this in mind. Providing
> some recognition to devs there whose modules become part of the
> core may be a better way to insure that projects that are started on
> bioperl-dev actually get finished, than to prescribe beforehand what
> kinds of projects may get started. I believe this follows the adage of
> liberality on what is accepted, and strictness on what is emitted.
>
> cheers, MAJ

The main reason I wanted a bioperl-dev is for some code or  
implementations that don't seem to fit on a branch or directly into  
core, but would definitely be of use.  The tendency in the past has  
been to accept anything that works into core (the 'bazaar' approach).   
Initially that worked well, but the long-term end result has become  
potentially unmaintainable code bloat.  Committing new code to a  
branch isn't a great idea either, primarily b/c the code may be lost  
to the branch if it isn't followed up and remerged into trunk.  And  
forcing the code to fit into bioperl (or vice versa, which happened  
re: Feature Annotation) isn't the best way either.

Like Hilmar, though, I don't want dev to become a (sandbox|code  
dumping ground) either, so I think some additional discussion is  
warranted if anyone else wants to chime in.

chris