Features Download
From: Fields, Christopher J <cjfields <at> illinois.edu>
Subject: Re: Google Summer of Code - BioPerl proposals
Newsgroups: gmane.comp.lang.perl.bio.general
Date: Tuesday 2nd April 2013 02:19:23 UTC (over 5 years ago)
On Apr 1, 2013, at 8:54 PM, Carnë Draug  wrote:

> On 1 April 2013 23:23, Fields, Christopher J 
>> On Apr 1, 2013, at 12:17 PM, Carnë Draug 
>>> Can I merge any branching between these and bioperl-live and set them
>>> up so you only have to run dzil on their repos?
>> I wouldn't worry about the branches, they are probably too stale.  Have
it so dzil works for the various repos from that project (it should
> I tried but I don't have push permissions for Bio-Root like I have for
> the other BioPerl repos.

Should be fixed now, that one repo didn't have team set, just owners.

>> We will likely need to think about having a stub Build.PL that can be
used for basic installation, but would be auto-generated based on the needs
for that repo (and so shouldn't be committed to).  This is mainly to help
git-savvy users, not devs; we don't necessarily want users to install dzil,
which had somewhere north of 40 or so dependencies IIRC.
> Bah! People using development versions should be prepared to act as
> developers. Otherwise they should be content with the stable released
> versions. Development versions are not meant to be stable. I see no
> reason to give users the chance to shoot themselves, specially when
> it's more work for developers and maintainers.

I agree (though the definition of when something is in 'development' vs
'stable/release' is very subjective).  I wouldn't do this unless requested,
though, and I think the current plugin bundle does have some basic
functionality that supports something if needed.

>> Re: versioning: I'm not particularly hung up on any particular
versioning scheme, but the key point is support.  It's easy for me to say
"as of bioperl v2 the installation scheme will be something completely
different" as opposed to doing so with v1.7.  Will installation of v1.7 be
the same is it was for v1.6 (or even similar)?  Will it install the same
modules by default?  We would be changing a key step in using BioPerl
(installation) w/o much warning.
> That is my idea yes. Exactly what happened with Bio-Biblio, it changed
> close to nothing. There were a few minor changes on the code to pass
> the tests already in place, bust mostly it was in POD to use the
> BioPerl's distzilla and podweaver configuration.
> Carnë

That works for Bio-Biblio, but my point is: would one be able to get an
old-school all-inclusive (e.g. install everything) bioperl?  Maybe the
answer should be 'of course not', and we should create a bundle to take
care of this instead.

I wouldn't worry about it, frankly.  We should just forge ahead, damn the

CD: 3ms