On 6/16/07, Jason Stajich <jason at bioperl.org> wrote:
> [...]
> Just to say I already went through all the steps of running cvs2svn
> myself and had problems gathering back out the branches and all the
> tags when I tried it. If you want to start with a smaller repository
> like bioperl-network or bioperl-db as the initial cvs2svn conversion
> script took quite a long time to run on bioperl-live.
Might this been a good opportunity to investigate partitioning
bioperl-live into sub-repositories? There has been talk in the past of
defining a set of "core" modules separate from other functionally
related groups of modules that would be viewed as optional extensions.
The goal being to help manage growth and simplify releases. There are
currently 892 modules under Bio/.
In addition to simplifying the migration to SVN, it would also have
other benefits. Say some new functionality or a slew of fixes were
added to Bio::Graphics. We could turn around a new Bio::Graphics
release quickly without having to work on getting various other parts
up to snuff that aren't related to graphics (Biblio, DB, PopGen,
Search etc.). Maintenance and releases of the various extensions would
be more parallelizable, orchestrated by separate ring leaders.
Over time, as a set of functionality matures, it would see fewer
updates and there would be less of a need for users to
download/install/test it. This could make bioperl easier to customize,
extend, and grok in general.
Long term, it should ease development and release cycles, but it will
involve a bit of near term bullet-biting. We'd need to get clear on
how to partition things, including modules, tests, docs, installation
logic, etc. and we'd probably need new integration tests to verify
that the subsets continue working together.
What do folks think? Would this SVN-based, re-partitioned bioperl-live
constitute a 2.0 release? Any volunteers to help assemble a roadmap
and milestones? Should I go on dreaming?
Cheers,
Steve