Categorization, relating email threads, ditch tasksel and extend capt? (Re: cleaning up our task packages)
>>>>> "Dirk" == Dirk Eddelbuettel <edd@master.debian.org> writes:
Dirk> Interesting timimg :)
I've noticed it too. I just got back on list, had ideas, and after
reading farther, found other threads about similar topics. Neat.
It's good to be back on debian-devel... that's iff I can keep up with
the traffic.
Dirk> I finally got a go-ahead from the previous task-science maintainer to adopt
Dirk> his package, which I found muddled (and buggy where it intersected with some
Dirk> of my packages). I posted a suggestion for a new one to d-devel last night,
Dirk> and so far only heard "break it up further into task-numerical-analyis and
Dirk> task-data-analysis".
<kmh-subtopic key="email user agents threading relating threads">
</grin reason="clever use of XML">
Noted... Uh, how can we combine two threads like this logically
somehow? Can the various email user agents deal with it in some
way? (they should) Can our web interface deal with it? Who marks
them as "combine" or "related"? How can that data be propagated to
everyone on this list? Control mails in the channel or out of
band? ... then our user agent software picks that up and edits
headers in personal archive so threads are displayed as related?
What would be good interface? How can we make it so that it's
easier to build a thread summary, without needing to spend an extra
two hours at it? (Think DWN, Kernel Cousin reports, or pulling
together threads into a summary and using that to build up an RFC
document, etc. etc...)
</kmh-subtopic>
<kmh-subtopic key="configurable limits on CC's">
The mailing list software ought to let us configure (per list with
a global fallback) whether we want our name stripped from the To
and CC headers of email remailed by the listserv. This way,
replies don't include you in the CC for lists you are a subscriber
to.
</kmh-subtopic>
<kmh-subtopic key="listserv pulls out and routes subtopics">
What if tags like that got the listserv to route subtopic segments
to the right people's "suggestion box"?
</kmh-subtopic>
Dirk> I'm of a divided opinion. I think Joey is right in limiting
Dirk> tasksel at its [...]
Hmmm. Similar ideas occured to me. We're on the similar wavelength
today. `capt' ought to support this also... it's analagous to the
"interpreter" vs "compiler" thing... one does it at runtime, the
other at compile time. Here's what I mean by that.
`capt' can use information from the apt-cache to build the data
structures it needs for selective display. It can do that dynamicly,
at runtime, and the selective display can be switched to any of
several modes. Filters, sorts, etc.
`tasksel' though, must be a smaller program so it will fit on a boot
floppy, boot CD, bootp/tftp, or netfetch setup where media size, ram
size, or bandwidth issues are prevalent. It can be data driven
though, by a file that is essentially a compilation of the relevant
data parsed from an apt cache matching the Packages for that release
du jour. You'd run a tool that creates its data file. Here we have
a consistency issue - that tasksel data must match the actual
Packages, etc. (This is disjoint from the consistency issue with
kernel version and modules.) That data file, since it must be
generated anyway under this scheme, could even be binary, designed to
be mmapped in by tasksel. Byte sex would not matter, since for each
arch, there would need to be a different set of installer boot images
anyway.
--
mailto: Karl M. Hegbloom <karlheg@debian.org>
http://people.debian.org/~karlheg/
Reply to: