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 [EMAIL PROTECTED]
