Re: Splitting imaging into two separate tasks
[discussion is probably more apropriate on debian-blends list and
I would prefer to continue there - please ask explicitely for CC
if you are not subscribed. For readers of debian-blends you might
like to read[1] ]
Hi,
On Fri, Jul 20, 2012 at 09:27:08AM +0200, Michael Hanke wrote:
> It wasn't meant as a philosophical statement arguing against the
> usefulness of tasks or their nature. It was meant as a technical
> question whether there is still need to maintain the tasks manually and
> separately -- or whether the could be auto-assembled from data the
> exists (or should exist) elsewhere.
Thanks for the clarification.
> Yarik could chime in here and explain that in NeuroDebian we essentially
> already auto-populate the tasks from a simple text-based database. But
> please read on...
Hmmmm, from my perspective tasks files just *are* a simple text-based
database ... but I'll read on.
> They could be of course. However, my _technical_ question is:
>
> Would it be more feasible to auto-generate taskfiles from a (future)
> database of respective task/domain/field of application tags that is
> generated from information that would be available from within a package
> (which is different from debtags).
IMHO the strength of the tasks files is that we actually do *not* depend
from information inside a package. In NeuroDebian the situation is
perhaps different because you are a small team that has agreed upon a
certain workflow and technical implementations and *all* packages. This
is an exclusive situation and even inside Debian Med we do have people
maintaining medical packages outside Vcs (and outside the team for years
see for instance [2]). In Blends like for instance Debian Edu until
recently not even any packaging team existed and it is forming slowly
now after realising that this is a successful concept and you get a
better grip on the packages in your focus.
If you might like to stretch the thing farther for instance to create a
task med-office or something like this which IMHO makes sense to some
extend to suggest a certain set of packages which makes a computer fit
for office tasks with some specifics of medicine it becomes clear that
maintainers of such packages will not be to happy to maintain extra
information inside their packages and I do not want to do this
communication about information to include into a package via BTS.
In short: No, it is not possible to inject Blends information into
package information. (BTW, I have even more arguments against this -
feel free to ask and I'll keep on.)
> My question is triggered by the fact that you already have a mechanismn
> to gather information from package VCS. I'm assuming that the same tool
> could extract tags and generate task files.
>
> There could be a list of agreed-upon tasks (they need a description
> anyway). However, maintainers could just come up with additional tags at
> any point. If the gatherer sees lots of packages with new tags, these
> packages are e.g. all tagged imaging, but there are at least two other
> tags all these packages are associated with -- in this case it would be
> obvious that the imaging task is worth splitting into two facets -- a
> decision that is based on data and is less dependent on the opinion of
> individual developers that have to read the right mailing list, and have
> time to discuss a potential split.
>
> I hope that explains my thoughts a bit better,
It explains your thoughts, yes. But I do not see in how far this should
be an enhancement over the current tasks files (database) approach.
Kind regards
Andreas.
[1] http://lists.debian.org/debian-med/2012/07/msg00211.html
[2] http://lists.debian.org/debian-med/2012/07/msg00181.html
--
http://fam-tille.de
Reply to: