[Bioperl-l] bioperl-dev or branch? : redux
Chris Fields
cjfields at illinois.edu
Mon Jun 22 19:20:14 UTC 2009
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
More information about the Bioperl-l
mailing list