[Bioperl-l] Splits again

[Chris Fields]

On Jun 28, 2007, at 5:31 AM, Hilmar Lapp wrote:

>
> On Jun 28, 2007, at 12:51 AM, Jason Stajich wrote:
>
>> ...It
>> seems like we really need to do this first so that we have a stable
>> release that can be followed by CVS -> SVN migration, then consider
>> major changes to the repository structure and release packaging, and
>> potential deprecation and incorporation of other modules.
>
> I agree we need to discuss a path towards 1.6, but I think that
> should be kept separate from the cvs->svn migration. Otherwise one
> stalls the other (by stopping people who seem to have the energy and
> motivation right now to do one but not the other) for no really good
> reason.

It's good to discuss it as long as it doesn't take time and energy  
away from other priorities.

>> I assume there is no chance that we'd have a 1.6 candidate by BOSC
>> next month?
>
> I'm not sure that's feasible to be happening but if someone steps up
> it maybe it is.

Maybe a 1.5.3 and (if we work hard on it) a 1.6 soon after.  Then  
maybe work on partitioning if everyone's up for it and a scheme is  
worked out.

>> Will it be productive to schedule a fair amount of time at BOSC
>> discussing how to partition out the packages into separate sub-
>> packages after we've done a successful release rather than trying to
>> change things right now?
>
> I agree. I also don't think that people are partitioning right now
> (other than the existing partitioning), though maybe I'm mistaken.

The original proposal was based on Steve's idea of splitting up  
core.  I don't think a partition is feasible at this point, at least  
until we put more thought into it  (our energy should be focused  
elsewhere), but it's well worth discussing as a future path.

At this time there are two proposals:

1)  Steve's and my 'split into discrete sections' proposal, where we  
split core into self-sustaining sections with a common core listed as  
a dependency, tying installation of all together with a Bundle or  
similar.

2)  Sendu's 'break everything up' approach where all modules are  
submitted independently to CPAN, with their own tests, dependencies,  
etc.

There are advantages and disadvantages to both approaches.  Not sure  
if CPAN would go for the latter (it's pretty drastic), but I don't  
know for sure.  If you want in on that discussion (in this thread)  
feel free to join in!  The more the merrier!

>> [...]
>> It would  probably mean moving Bio::Graphics, Bio::DB::GFF and
>> Bio::DB::SeqFeature and gff tools for Gbrowse into separate packages
>> so they could be released more regularly on par with Gbrowse
>> schedules.
>
> Possibly. I'm not fully sure why those modules couldn't also be
> released more often out of the "main trunk" of modules. In Java/ant,
> it'd be relatively easy to write build script filters that select the
> appropriate modules and package them on the fly. I'm not sure whether
> the build tools for Perl can do that too, though.

Both approaches above would probably use Module::Build to install  
other bioperl dependencies, each of which could have it's own  
dependency set, possibly using a Bundle to tie everything together.

>>   Also I think someone needs to figure out Bio::Tools::GFF
>> vs Bio::FeatureIO -- what do we want to do?
>
> I believe FeatureIO has the ontology download tied into it?
>
> 	-hilmar

 From recent posts here and on the gbrowse mail list by Scott and  
Lincoln, it seemed like they were moving away from using Bio::DB::GFF  
and were trying to get users to switch to Bio::DB::SeqFeature.  Maybe  
should get a more direct response?

chris