[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bio-Linux 9



On 6/22/18 9:23 PM, Andreas Tille wrote:
> On Fri, Jun 22, 2018 at 05:53:40PM +0200, Steffen Möller wrote:
>> @all, anybody who minds if I remove all software from our red list that
>> has stale URLs? Hexamer came to mind. Ohters just needs an update of
>> their URL like GenoGrapher and yet again others should possibly be
>> removed because there is no real interest?
> I'd be **really** happy if somebody would check that list, remove and
> fix what needs to be removed or corrected.  There is no point in simply
> assembling a list of software which is outdated and will possibly never
> be packaged.

And if we just remove that red section? After all, we do have ITPs for
what red is meant to express. So, I would rather have red as an indication
of a delta to conda - or to bio-linux to stay in the thread.

To digress a bit - to care for single packages is a bit from the past. It
is a requirement, but nothing that a distribution can sell. We should
find ways to truly present tasks on our tasks page. And this means
that we present small workflows. The message to transport is "anybody
using our distribution has everything needed to assemble and annotate
a whole genome and the method section of your paper should say '...'."

To digress a bit more, quite some of us are employed for the bioinformatics
support of a certain routine. And this routine changes all the time
because of new versions of tools (technical), new tools (more than just
technical) and new flavours of data (almost biological).  So, for these
fully-employed bioinformaticians the "official" workflow is more like
a template for what they are after. This is why I am so much after the
RRIDs to be added to our packages - there will be abstractions from
current established workflows towards an interaction of RRIDs and there
will be suggestions to substitute RRIDs with each other. The main question
for me are
 a) do we know what workflows we are supporting
 b) do we have all
   b1) the man power to keep all these packages updated
   b2) the contacts into the community to decide for the right packages


Sorry for tall that text. So, I propose to
 * remove all from current red packages
 * reinterpret it as
    - packages other distros have that are of interest for us
    - packages that we should have because these are at the cutting edge
of a workflow we support [once we have decided for workflows]


Best,

Steffen


Reply to: