[Bioperl-l] Priorities for a bioperl-1.6 release

[Alex Lancaster]

>>>>> "SB" == Sendu Bala  writes:

[...]

SB> # I agree that this 3-way split seems reasonable # bioperl-main
SB> would consist primarily of the 'leaves' of the module tree, mostly
SB> parsers and the like which, whilst 'stable' and tested should
SB> still be split away from core because the data sources they parse
SB> could change format slightly # bioperl-unstable, better
SB> bioperl-bleed, would feature brand-new stuff, be it new parsers
SB> for totally new formats, new APIs that do something not thought of
SB> before etc. When they are complete, bug-free and have stood the
SB> test of time they get moved into bioperl-main.  (It is not a place
SB> for all new commits; bug fixes to something in bioperl-main would
SB> be committed to bioperl-main) # The current splits (bioperl-run,
SB> bioperl-network etc.) do not get their own core and bleed
SB> variant. Anything they need for core functionality would enter the
SB> single bioperl-core, anything new would enter the single
SB> bioperl-bleed, and anything stable would be in their own
SB> bioperl-[package]

SB> Discuss :)

While on the subject of how to split up the bioperl package, spare a
thought for upstream package maintainers.  The Fedora package for the
bioperl "core" that I now maintain is currently a single package which
makes it easy to get reviewed, included in the distribution and
updated/maintained.  (bioperl-run is a separate package).

While I agree that bioperl is now perhaps a little too monolithic, I
thinking splitting it up in a too fine-grained manner like CPAN might
go too far the other way.  For Fedora, each package would then need to
be reviewed and updated separately.  Similar issues might apply for
other distros (such as Debian/Ubuntu).

I think something similar to the three-way split proposed sounds like
a good compromise, so long as everything that a "basic" user of
Bioperl can install most of the functionality in the current "bioperl"
package in (at most) 2-3 packages.  

One model to look at might be the gstreamer model which has a "core"
(gstreamer) and "gstreamer-plugins-base", "gstreamer-plugins-good",
"gstreamer-plugins-bad" and "gstreamer-plugins-ugly" modules for
plugins, see:

http://gstreamer.net/

Alex