[Bioperl-l] bioperl-dev or branch?
cjfields at illinois.edu
Fri May 22 03:38:08 UTC 2009
On May 21, 2009, at 6:31 PM, Robert Buels wrote:
> Hilmar Lapp wrote:
>> something to be folded into the main trunk sooner or later, what
>> would be the reasons for not putting it into a branch of the main
>> repository? If we are putting it into a separate repository, we're
>> waiving a lot of svn's support for merging and resolving concurrent
> Just to clarify, it doesn't look like bioperl-dev is actually in a
> separate repo, it's just separated from bioperl-live as a different
> distribution, but still in the 'bioperl' repository. So it seems to
> me there's no need to worry about being able to merge from it.
> Sorry if I'm butting in on the larger organization issue here, since
> I don't exactly have any history with this group, but here are my 2
> cents, they may or may not make sense: I would agree with Sendu's
> assertion that there doesn't really seem to be a need for a separate
> distribution for highly experimental things, that role would
> probably be most straightforwardly performed by a branch of the
> appropriate bioperl-* distribution.
Ah, but we're trying to put core on a diet and not arbitrarily drop
code in. There's lots of cruft, dead hunks o' code floating about in
bioperl that could be moved/removed. I have no qualms on getting rid
of stuff that no longer works or never worked as intended (see my
reverts on feature/annotation, or deprecation/removal of modules in
the last release). I would like to see some unmaintained core modules
go the same route (I'm staring directly at you, Bio::SF::Annotated).
> In fact, having a separate bioperl-dev distribution could actually
> be a headache for anybody wanting to actually install it (as in make
> install from a tarball or something), since anything radioactive
> enough to be in there is quite likely going to *conflict* namespace-
> wise or at least functionality-wise with what's in bioperl-live.
Nope, that's not it's purpose (we would branch for that). If our
regression tests are worth their salt they should catch issues with
code merged back in.
> And by the way (I may be opening a can of worms here), wouldn't
> bioperl-live be more appropriately called bioperl-core?
Yes, it should (as jason points out). As mentioned we could alias it...
More information about the Bioperl-l