BPN: BioPerl Nouveau [Was: Re: [Bioperl-l] distant thoughts from a dinosaur...]

[Aaron J Mackey]

> >     --- should be designed in a iterative fashion of discussion,
> > working code proposal (early on) prototypes (mid way) moving quickly
> > to real skeletons which are expected to last a long time. We should
> > avoid a massive navel-gazing exercise with no code.

A few of us had discussed (offline) the idea of a new repository,
"bioperl-experimental" that contained a skeletal base Bio::Root::
distribution and not much else; furthermore, various ideas/proposals would
live in their own branches off this repository ("freaky" or not).  I'm
happy to spearhead this effort.  Note that this is *NOT* BioPerl 2.0 -
this is a place to play with new core ideas that may or may not be useful
for BioPerl 1.4, or should be included in a BioPerl 2.0 when such a beast
begins to exist.  Of course, if wildly successful, bioperl-experimental
could later become bioperl-2.0-live, but it doesn't necessarily have to
be.  I hope that point isn't too subtle to appreciate.

But here's how bioperl-experimental might work; it centers around the idea
of a "Hero" for any new experiment:

1) there's bioperl-experimental-l and bioperl-experimental-dev mailing
lists for discussion and commits, respectively.

2) The HEAD branch of bioperl-experimental would contain the bare minimum
of Bio::Root:: modules necessary to "Do Stuff".  This provides a common
starting point so that experiments don't need to build from the ground up
(but of course, nothing prevents an experimental branch from blowing those
away with replacements).  If a branch depends on additional Bio::Perl
modules, they should be added to the branch (although if it seems they
should be in the core HEAD, we can have some discussion about it).

3) "Heroes" for a given idea would be responsible for writing some form of
RFC, proposal, rant, and/or stream of consciousness about how things
should work, or be implemented.  The idea here is to have something public
that "anchors" an experimental branch (besides "the freaky collection
branch").  Heroes would be expected to keep this document updated with
respect to alternative viewpoints, discussion summaries, etc.  Think Perl
6 RFC process without so much huffing and puffing.  These documents would
actually live in the HEAD somewhere, and provide instructions for
obtaining the relevant branch (i.e. tell us what the branch tag is).

4) branches fork off the HEAD (after the heroes's document(s) are in
place), and then are carte-blanche.  Break anything, add anything, do
anything.  Then we'll see what really works and what really doesn't.

5) Akin to Nat's idea of gradual reintroduction into the core, particular
experimental branches that seem very worthy of becoming "core" could at a
later point be merged back into bioperl-experimental HEAD;  these patches
could be merged out to various branches as the heroes want (although
someone (i.e. me) will need to ensure the correct order of tagging and
branching and merging so that we don't get into crazy CVS duplicate
merging madness - this might also be the point to try to convince us/me
of some other versioning tool that would make this bit easier).  Whole
branches themselves can, in theory, get merged directly into other
branches if the heroes start to collude with each other!

6) Crud-removal: dead branches should get removed (only after the
appropriate amount of trying to contact the heroes and whatnot).

7) Nobody calls this effort BioPerl 2.0; it's experimental, nouveau
bioperl, nothing more.  Perhaps it's actually BioPerl 3.14, we won't know
until we get there.

> >     --- We are bound to have a proposal to change the start from
> > 1 to 0 of sequences. We should have some reasoned discussion and
> > then vote/or leave to the leader's taste (I prefer the latter...)

Our first experiment!  Heroes to the battlefield!

> >     --- should be actively lead by one or a very small number of
> > people who have serious bioinformatics experience

the idea of the experimental branches is that we can divide and conquer; a
small number of people don't have to do everything by themselves.

> >     --- who should **not** be me, as I am clearly going to be happy as a
> > pig in mud with the Bioperl 1.x series for a long long time ;), I am
> > a dinosaur compared to some of the young-crazy-boys-and-girls out there
> > and will probably be coding $seq->trunc($start,$end)->revcom() for
> > the rest of life...

And you'll be the first to try to get that to work with the new
experimental feature model, right?

> >         - whoever codes it wins the argument
> >            aka:
> >         - working code trumps abstract arguments

But see Aaron's Corollary to Ewan's Rule #1:

* one person's working code should not trump someone else's alternative
  abstract argument that *could* be shown in code, but has not yet been
  written because we all have paying day jobs that get in the way and
  often have only a few minutes to read over the gobs of proposed stuff
  and respond with a "Hurm, are you sure that's the right thing to do when
  you might just (A, B, and C) instead?".

A Hero should test any reasonable alternatives and respond to the
challenge with gusto (not a snivelling "I was here first, so nyah nyah").
But in the end, Ewan's rule holds: it's the heroes' choice to do what they
want in their branch;  detractors can create their own branches (when they
have the time ...)

> >              - testing as much as possible
> >              - documenting sensibly

These two end up being one of the barriers between moving from a branch
onto the HEAD.

Enough for now,

-Aaron