[Bioperl-l] Withdraw Bio::Graphics and Bio::DB::SeqFeature from bioperl distribution?
Dan Bolser
dan.bolser at gmail.com
Mon Nov 10 22:01:17 UTC 2008
2008/11/10 Chris Fields <cjfields at illinois.edu>:
> Lincoln,
>
> I agree about the glacial pace. It's also feeling more and more like only a
> couple of active developers are working on it (so the more that chip in the
> better). Furthermore, the code base is so large now at this point it feels
> like steering an aircraft carrier with an oar and has become very hard to
> work on.
>
> I don't have any objections personally if you want to withdraw
> Bio::Graphics/Bio::DB::SeqFeature, but how much work would that be (scott
> mentions a few issues I see)?
>
> Personally, I think if Bio::Graphics remains in bioperl we have to do two
> things. We should release the full bioperl-live as-is to CPAN as an
> official release (TODO any bugs) ASAP. No RCs; we'll post point releases
> along the way for bug fixes (I like the 'release early/release often'
> mantra). I can work on this over the next couple of weeks, aiming for
> Thanksgiving for a 1.6, but I probably won't get rolling until this weekend
> (too much going on this week). We can aim for more regular point releases
> then.
>
> Following that, I think a more stable long-term solution is to split off
> some of the non-core-like modules so that we can speed up releases (this has
> been discussed in the past,
> http://www.bioperl.org/wiki/Proposed_1.6_core_modules). Basically, make a
> 'bare-bones' well-tested core containing the base classes and interfaces
> that remain stable long-term, such as Bio::Root, Bio::Seq/PrimarySeq,
> Bio::SeqFeature::*, with as few dependencies as possible.
>
> Everything else requiring constant maintenance, not actively supported, or
> under development would go into a separate monolithic distribution listing
> the new core as a dependency; this could feasibly have it's own release
Sorry for the potentially dumb question, but why have an overall
release cycle at all?
BioPerl is so large and diverse, asking for a new 'release' is almost
like asking for 'the next release of CPAN'. Can't inter-module
dependencies just be handled in the same way as in the rest of CPAN,
with everything released asynchronously? Is BioPerl just too tightly
woven for that to happen?
Dan.
> schedule. If we go this route, Bio::Graphics and related could also be in a
> second distribution (and thus also on a distinct release schedule). This
> could be worked out in a separate subversion directory, so bioperl-live
> wouldn't be affected until we switch over. Does that seem feasible?
>
> chris
>
> On Nov 10, 2008, at 2:25 PM, Lincoln Stein wrote:
>
>> Hi All,
>>
>> The glacial pace of official bioperl releases is interfering with my
>> ability
>> to package GBrowse 2.00 into debian and rpm packages. Is there any
>> objection
>> if I withdraw Bio::Graphics and Bio::DB::SeqFeature from the bioperl
>> distribution and turn them into independent CPAN modules?
>>
>> Thanks,
>>
>> Lincoln
>>
>> --
>> Lincoln D. Stein
>>
>> Ontario Institute for Cancer Research
>> 101 College St., Suite 800
>> Toronto, ON, Canada M5G0A3
>> 416 673-8514
>> Assistant: Stacey Quinn <Stacey.Quinn at oicr.on.ca>
>>
>> Cold Spring Harbor Laboratory
>> 1 Bungtown Road
>> Cold Spring Harbor, NY 11724 USA
>> (516) 367-8380
>> Assistant: Sandra Michelsen <michelse at cshl.edu>
>> _______________________________________________
>> Bioperl-l mailing list
>> Bioperl-l at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>
> Christopher Fields
> Postdoctoral Researcher
> Lab of Dr. Marie-Claude Hofmann
> College of Veterinary Medicine
> University of Illinois Urbana-Champaign
>
>
>
>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>
--
http://network.nature.com/profile/dan
More information about the Bioperl-l
mailing list