Re: Splitting imaging into two separate tasks
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".
> 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"?
> 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.
> 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).
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: