Re: cleaning up our task packages
I'm going to chime in with my non-DD-ness. ATM the people who decide a
task package are not the ones who will ever use them. Tasks were by
definition not for developers, but for FNGs--DD's should know what they
want. Has anyone gone to -user and ASKED? I would submit that the first
step in reformation of task-* would be to find out what tasks are required
"out of the box" by users, not what tasks are thought to be required by
DDs. I think that both a task-gnome and a task-KDE are appropriate, but
why is there a task-debian-devel and FOUR task-python-* s? It looks ATM
as if the task-* setup is just becoming another trash repository of
meta-packages that wouldn't make it on their own. There are waay too many
-dev tasks, but the obvious one is missing: the first thing any FNG builds
on most unices is the kernel: in fact, I really wonder at the person who
thinks that they're qualified to be a DD yet hasn't built a custom kernel
at one time. The other thing I would submit is that wishlist bugs on
task-* packages become RC--if they're an issue with something under the
aegis of the task, the bug should be forwarded, while if the task has a
feature request that isn't being dealt with, the task-* is failing its
mission. This would have the effect of minimizing unnecessary (and
probably necessary ones too, but you can't have an omlette...) task-*
packages beacuse of the "RC hunt" at the ends of freezes.
Just my opinion, mostly so's I get "I told you so" dibs when someone else
comes up with it later...
On Thu, 7 Dec 2000, Joey Hess wrote:
> Cheng H. Lee wrote:
> > I agree that it is a bit long; however, I think the best way to resolve this
> > would be to tell the user that there are more tasks listed below
>
> people_who_have_never_run_tasksel_lately_if_at_all++;
>
> > Some of these tasks should be folded into one, e.g. the multiple KDE or GNOME
> > tasks; most of the key programs related to these tasks would then be installed
> > and the user can then trim it using apt or dselect. Other tasks, however,
> > shouldn't be consolidate, especially the programming stuff. I say this because
> > doing so would pack to many separate things into the task meta-package. For
> > example, if I were interested in C programming only, I would install the C
> > programming task package; if instead, it were folded into a single programming
> > task package, I would end up with a lot of stuff I don't want or need like
> > Python or Perl.
>
> Well fine. This is why I want to come up with a set of guidelines and
> put them in policy, then we can apply them to individual cases.
>
>
--
Pardon me, but you have obviously mistaken me for someone who gives a
damn.
email galt@inconnu.isu.edu
Reply to: