[Bioperl-l] bioperl reorganization
Robert Buels
rmb32 at cornell.edu
Fri Jul 17 09:08:18 UTC 2009
Chris Fields wrote:
> Yes, I agree. However a large set of modules in bioperl were
> effectively donated by the author, so they will fall to the core devs to
> maintain by sheer property of legacy.
This is a very sticky point. The only way I can think of would be to
have each distro have a "principal maintainer", that is the go-to guy
for issues related to keeping it running, but can beg and cajole others
to help. At least there will be fewer problems per distribution, since
they would be smaller. If a maintainer has to stop, he has to find
somebody else to do it, or the package sits there and bit rot sets in.
That's just how it goes. If it's important enough (like if it's
depended on by a dist that IS maintained), somebody will pick it up.
> On bugs:
<snip>
> On API and the 'chicken-or-egg' issue:
<snip>
> What I would like is have the various breakaway Bio::* either fall back
> to Module::Build if Bio::Root::Build isn't present, or just use
> Module::Build. My suggestion is to just use Module::Build directly, but
> we could scale down Bio::Root::Build to respect the Module::Build API
> (thus allowing it as a fallback).
I'm not sure about this, I'm not an expert on the ins and outs of
subclassing Module::Build.
One idea I do have, however, is that we might think about using an xt/
directory for intensive and network-based tests that are not meant to be
run by automated installers, which could help simplify the test and
build code. I've heard that this is a pretty common practice in other
projects.
=====================
Anyway, let's develop some concrete plans. I would say that the plan at
http://www.bioperl.org/wiki/Proposed_core_modules_changes is a
half-measure, in light of the successful (painless?) Bio::Graphics
extraction.
Here's a new proposal:
1.) renew/construct the Bundle/Task::Bioperl, get it pulling in all the
current Bioperl modules as dependencies (or however it works)
2.) start repeating the same extraction procedure used with Bio::Graphics:
* identify a candidate set of modules in bioperl-live to be extracted
into their own distribution, propose the extraction on the mailing list,
get some kind of agreement
* make a new component in the svn repository (alongside the
bioperl-live and other dirs) named something like
Bio-Something-Something, with trunk/, branches/, and tags/ subdirs.
* svn cp modules into the new trunk/lib/, tests into trunk/t, scripts
into trunk/scripts, and write a Build.PL just like the one Lincoln wrote
for Bio::Graphics.
* when the extracted copy looks good, use svn merge to port any
changes that happened in trunk to the new extracted modules if necessary
and test.
* delete the old copy from bioperl-live/trunk.
* identify a new candidate set of modules, propose on the mailing
list, and repeat
2.5) continue releasing 1.6.X bugfix releases while this is going on.
3.) when bioperl-live is down to a truly reasonable core set, (fewer
than 10 modules might be a good target), rename it to Bio-Perl-Core, go
through a round of testing, and push them all to CPAN at once.
Task::BioPerl will have dependencies on the module names, I think, so it
will continue to install the same from users' perspectives, it will just
be downloading different dists.
4.) repeat steps 1-3 with bioperl-run, and maybe others.
Thoughts? If people like it, I or somebody else could put it on the wiki.
And of course, I volunteer to put in a lot of work on this. I'll try to
see if I can identify some other likely extraction candidates as a
preliminary step and report back to the list.
Also we need some more people besides just me and Chris talking and
thinking about this, these are large reshufflings being proposed.
Rob
More information about the Bioperl-l
mailing list