Re: Splitting imaging into two separate tasks
On Thu, Jul 19, 2012 at 04:15:35PM +0200, Andreas Tille wrote:
> On Thu, Jul 19, 2012 at 02:34:02PM +0200, Michael Hanke wrote:
> > On Wed, Jul 18, 2012 at 09:04:34AM +0200, Andreas Tille wrote:
> > > I was wondering whether the user base for these different kinds of
> > > imaging applications is distinct and a split might make sense here.
> >
> > The resulting potential duplication of packages in multiple tasks is an issue
> > -- not just for imaging. The underlying problem is, of course, that the
> > tasks are not orthogonal.
>
> Could you please be more verbose why this is actually an issue (in case
> you are using "issue" in the sense that it is a problem we need to
> handle somehow)? IMHO tasks actually can not be orthogonal and this is
> the case by design. If we dive into usual office use: lowriter is used
> to write professional letters and also by pupils doing their homework.
> Completely different tasks - same programm. As I repeated often enough:
> Tasks are no exclusive categories by design and I would not regard this
> as an "issue".
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.
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...
> > Now that more and more information about blends is gathered directly
> > from VCSs, maybe we already have the infrastructure to assemble tasks
> > from tags stored in a VCS?
>
> You mean tags in terms of "DebTags"?
See below...
> > If that is the case, it might be a way forward to a have debtags(-like)
> > scheme to assemble tasks from packages, where any package can be
> > assigned to any task, simply by adding the corresponding tag.
>
> The problem is that you need to touch a (potentially large) set of
> packages regarding a defined set of tags. Simply maintaining a single
> file comes rather cheap compared to this.
>
> Also DebTags propagation is not predictable in time (it depends how much
> time DebTags maintainer will be able to spend into manual inspection.
> I'm continuosely thinking about leting DebTags influencing the set of
> packages in a task but failed to come up with some reasonable
> suggestion. The problem is even in the very beginning: You need some
> volunteers to start discussing on debtags-devel list about a reasonable
> set of tags. This first step creates a lot of friction we can easily
> circumvent with the task file approach. I do not blame debtags-devel
> for this - I'm rather afraid that from our team only a small minority
> would volunteer to do the discussion (we had this in the past) -
> specifically when considering the fact that there is no visible outcome
> of the discussion as long as no technical implementation to effectively
> use DebTags somehow rewards the invest of time.
That is why I wrote debtags(-like). The idea is the same. The scope,
however, is a bit different. We are probably looking at a tagging
mechanism from a different angle than the more general debtags.
Technically it is pretty much the same though....
> > In this scenario, there seems to be very little cost of having
> > arbitrarily fine-grained tasks (and any number of them).
>
> I fail to see the point why tasks files could not implement an
> equivalent set of fine-grained tasks (of any number).
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).
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,
Michael
--
Michael Hanke
http://mih.voxindeserto.de
Reply to: