Re: BioPerl long-term, was Re: dependencies on perl version

On 6 February 2013 22:11, "Fields, Christopher J" <cjfields <at> illinois.edu> wrote:
> [...]
> So:
>
> If it means targeting performance, backwards-compatibility be damned (using Devel::NYTProf?), we do that.
>
> If it means creating a new Bio-NGS repo to focus some of these efforts, so be it.
>
> If it means we get away from the Java-based interface stuff in favor of something more Perl-like (roles
anyone?), then I'm all for it.
>
> If it means we modularize BioPerl so this can be done, well, you probably know where I stand (yes).
>
> If it means this is to be BioPerl 2.0, then let's move that direction, sooner than later.
>
> But I can't do it alone.  We (not just me, but we) need to drive the direction we take.
>
> First one who codes gets the gold ring.

Hi

I know I'm not much involved with bioperl development but here's my
suggestion as maintainer of another quite modular free software
project. I swear I'm not promoting it. Skip to the last paragraph for
the very short version.

Octave Forge is now a collection of packages for GNU Octave, each
released independently whenever its maintainer sees fit. But it wasn't
like that before. For a long time, everything was released at the same
time, there was no independent packages. Then it was decided to split
it into sections: main, extra and nonfree (free software dependent on
non-free libraries, now purged), and inside those, it was split into
packages, each with its own maintainer. But some packages were (and
are) more active that the others. Some packages even came from single
contributions and we never heard from the authors again. And so, with
time, cruft settled in.

We didn't want to remove the code, but no one was interested or
comfortable enough on the field, to fix it either. Packages that had a
much more active development were being dragged down by code that no
one was maintaining. So we broke with that and each package is now
released independently. We have packages that haven't been released in
3 years yes, but that just shows the packages that no one cares about.
Those have been marked as unmaintained and anyone can come around and
make a release if they care about it.

As the maintainer of the project, I do *not* make the releases of the
packages. The package maintainers prepares everything and uploads
them, I only run a handful of tests (takes me 10min), upload it to our
server, and make the official announcement. I am also the maintainer
of one of the packages, and have often made releases of unmaintained
packages because I needed it. That's to show, if they are important
enough for someone, they will get a release somehow. If they are not
important, why would we waste our time on them anyway? We now around 5
package releases per month, many of them being minor releases with a
handful of bug fixes. Preparing a release of a small package is much
easier and much less trouble than preparing a giant release
encompassing all of them at the same time.

Short version:
I'd recommend to split the project into much smaller ones. Some of the
small ones will wither and die but those are the less important ones,
and will allow the others, the ones that people care about, freedom to
grow faster. Bioperl would still be just one project, that
incorporates a hundred or so of smaller modules. Let those who care
the most about a specific module to take care of it and make the
releases. Releasing a module becomes much simpler, which means more
releases, more activity, and the smaller code base for each module
also make it less intimidating for new contributors.

Carnë