On Mon, 23 Mar 2009, Felipe Sateler wrote:
The DeMuDi project is dead AFAIK.
This fits to my observation.
The 64studio spawned from it, and can't be a pure blend. Actually the demudi team merged with the Debian Multimedia Maintainers, so we now work together.
That's really good.
I would suggest removing it from the blends list (although the section on why demudi/64studio couldn't be a blend is useful to highlight that blends are _in_ Debian).
I'd suggest to keep it for some while there for the purpose you mentioned except if there is some new effort taking over the role of a Blend (see below).
There is an effort to support multimedia, a merge of the 2 previous efforts.
This is really godd news and gives some hope.
After reading the documentation, I still don't know if a blend is useful for us. Blends seem to be some kind of cooler tasks, is that true?
Well, the terminology was taken over from tasksel at some former point in time - but it is a little bit more.
For them to be really useful there should be clearly defined use cases that justify creating the metapackages and tasks, for which I'm afraid there aren't in the multimedia world. Other than ardour or audacity, every multimedia user will probably use a different set of tools for doing their work (ie, there are lots of alternative software synthesizers/effects processors/whatever). If there is no such clear set of tools, is there a point in creating a blend?
I'm not sure whether your point of view is based on your large amount of knowledge you might have about this field. You definitely know what to use and where to look at. Assume a person who is installing Debian the first time. Which advise would you give if this person might ask you: What Multimedia software is inside Debian. What should I install for a start. Which applications should I try to find out which might fit my needs best? I can not imagine that multimedia is that different from other Blends. Look at the Debian Med biology task: There are more than 60 Dependencies inside Debian and there is not a single user who is using them all. We sometimes consider to split this up to some extend but did not until now. The fact is if a biologists asks you: What biological software is inside Debian? You can simply answer: Lock here: http://debian-med.alioth.debian.org/tasks/bio.html What should I install to get ready for work quickly? apt-get install med-bio For sure this installs several applications which are not needed by every person - but this is no exception to any other method to install a group of software. Metapackages are builded that way that you can deinstall every application because it uses only Recommends. So the user can start, try and in case of get bored by something remove a package later. Blends are intending to give the flat package pool some user specific structure which regards the needs of a certain group of users. And you as the multimedia developers are the people who know these users and might be able to prepare the system as good as possible. I might imagine certain tasks (please be patient - it is a suggestion of a poor user regarding multimedia stuff, just correct me if I'm wrong about your purposes): sound-recording sound-playing video-recording video-playing image-editors image-viewers note-editors (for noteedit - no idea whether this is a reasonable category name) ... Probably syncing with existing DebTags (I did not checked these) should be a good advise. Probably more fine graining needs to be done. At least I would *really* love to have an overview about these categories in Debian. Technically you might also approach this by applying DebTags and my goal is to technically merge DebTags and Blends technique stronger in the future. But as far as I know there is no such thing like a tasks or a bugs overview based on DebTags. Moreover you are able to include packages into your focus which are maintained by maintainers who are not joining your Multimedia Team (for whatever reason). I hope I was able to give some reasons why a Blend makes sense. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org