[Bioperl-l] How to handle bugs in bioperl 1.4 on CPAN?

[Chris Fields]

...
> However, when view as an issue related to the setting of a
> policy for the whole project, then it makes sense to have a
> policy saying for how long a stable release will be
> supported, and when and in which case bugfixes that are committed
> to and tested in the development branch (as it should be)
> will get merged back to stable.

In a project this large which relies on a lot of outside resources
maintaining API and availability at all times, having a completely bug-free
fix for any reasonable length of time is impossible.  As a small example,
almost every time NCBI changes BLAST output, it breaks our text parsers, and
though we recommend using the BLAST XML format parser (which is much more
stable), almost everybody continues using text parsing and wants that fixed.
Now, NCBI routinely changes their BLAST version about every 3-6 months w/o
notification, so remote BLAST parsing can break at any time.  Fold into that
any software changes that change output or API (PAML comes to mind).  Fold
into that remote database changes (EBI interface to Swissprot).  Oh, let's
not forget sequence format changes (recent SwissProt and GenBank changes).
And, worst of all, we can't expect them to maintain API or output b/c
they're updating based on user input/suggestions or bug fixes which require
them to make changes.  What's 'stable' about that?

It's very easy to say you want something and then not volunteer to do it; if
you want something then put forth the time and effort to get it done.  Put
your money where your mouth is (as they say in my home state).

Again (for the third or fourth time now), putting together a release takes
some time and effort.  I actually think it takes more effort than Hilmar
suggests; either way, it requires someone to act as the leader (release
pumpkin) to handle changes, and I don't see anybody stepping forward.
Personally, if I have the time, maybe I'll handle an interim release, but
I'm looking for a job starting in the fall as well as finishing up research
for publication so that will take up almost all the time I have.  As Hilmar
says, if you want to do it, fine.  Realize, though, many many changes have
been made since 1.4 and many more will likely be made on the road to 1.6

> I'm not knowledgeable enough about the bioperl release
> engineering process, nor about the internal development
> process, but just guessing I'd expect that whenever anyone
> submits a bugfix, it should be the responsibility of
> the committer to check (against the project policy,
> (written or implicit) or with the core developers in a
> difficult case) whether the fix should be committed to more
> than one branch.

This is a large open-source project with a ton of developers all over the
world.  Check out the AUTHORS file; it's at best incomplete and still has
about 100 contributors.  

(Hey, my name's not on there!!!)

> A patch like the one that started this thread, should have
> been committed to the 1.4 branch without too much thinking.
> And it would have cost the committer only a few seconds more
> of her/his time.
> 
> But you only get this by setting and enforcing a policy.

You need to realize what this project is, what it is not, and how it
evolved.  A little history lesson might get you (and others) to understand
just how complex it all is (and how old some of the code is).

http://www.bioperl.org/wiki/FAQ#Can_you_explain_the_Object_Model_design_and_
rationale.3F

explains a bit on the project design.

http://www.bioperl.org/wiki/History_of_BioPerl

explains how BioPerl came to be.  

This is not a job or a company but an open-source project; it's origins are
based in the scientific community.  You're probably right about the person
not committing the change to the 1.4 branch.  We probably should have a
policy for commits to stable releases.  But how can we logically rationalize
doing so now for 1.4, almost three years hence?  We're post 1.5.1 and likely
going into 1.6 as we speak.  It's too late for 1.4 changes IMHO, frankly,
but you're welcome to try.  I don't think it's worth the effort.

As for policy enforcement, what would you want us to do?  This is a
volunteer effort.  Fire him/her?  Frankly they should be commended for
getting the fix committed in the first place, and if someone points out that
it should be committed to the 1.4 branch then fine; it shouldn't be hard to
do so even long after the commit to the main branch is made.  It just
requires someone to do so.

Again, this is NOT your typical CPAN module with one or two developers or a
project that relies on doing one thing very well.  This project has over 100
developers and is supposed to do everything adequately (and many things very
well). 

> After a number of these fixes has accumulated, then making a
> new release shouldn't represent too much effort, nor it
> should be expected that the tests that passed before would
> break now. And in the worst case (no tarball release),
> people can be directed to obtain the most current 'stable'
> code from the repository, containing all bugfixes.

You can download a tarball from the latest CVS code at any time.  There is a
link for doing just that at the bottom of the anonymous CVS page:

http://code.open-bio.org/cgi/viewcvs.cgi/bioperl-live/

Chris