Re: Please Improve Debian for Multimedia Production
On Wed, 25 Mar 2009, Felipe Sateler wrote:
Could you elaborate a bit? From what I gather (after reading the docs and
skipping through the pages you have referenced), all I see are tasks (enhanced
with metapackages with Recommends), and a nice web frontend. I'm pretty sure
I'm missing something here.
Perhaps some clarification is done below - if not, just ask again.
If a person asked me that giving me the freedom to choose OS, I would be at a
loss. For example, if somebody asked me: What should I install to get started
in sound synthesis? (A more concrete example, and which I know best) I would
not know what to say. There are big graphical sequencer and synth, like lmms,
or graphical synths like puredata, or text synths, like csound or
supercollider. Which one would be best? Install all of them? IME, people learn
a program/language and stick to it. It's like trying to create a Software
Development blend... it's just too broad and defined by personal preference,
with no clear better packages.
I think I understood your point. But to enable people developing their own
taste they need to be informed what to choose from. It's like a restaurant
where you choose from a menu. Currently we are lacking a complete multimedia
"menu" in Debian. Well, sure the applications will be installed in the menu
of your desktop if you if you installed the according package - but there is
no central place to pick the packages which might be interesting. Just take
me as a more or less multimedia ignorant person I would have a hard time to
find out all the relevant packages for graphical sequencing so I'd be really
glad if there would be a tasks page which assembles the short descriptions
and links to the homepage of the projects to enable a quick overview.
In how far it is different for instance to Debian Junior's puzzles page.
There are a lot of nice puzzles in Debian and you will finally pick some
favourites of them. So why not presenting a reasonable overview about
what is there?
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) ...
Although I wouldn't choose those tasks[1],
Sure - I told you I'm uneducated about your work - one reason more for
you to make the tasks better, right?
but lets go over them to illustrate
my point. What should we put into sound-recording? All of them?
Yes. Why not? If there are "bad ones" which should not be Recommended
or Suggested I wonder why they should hang around in Debian at all.
The X more popular according to popcon?
No. Adding popcon stats to the tasks files is in the upper quarter of
my todo list. People can decide themselves whether they want to try
a package with low or high popcon first.
The ones I use?
No. This contradicts your own arguing.
Also, use cases overlap: I don't
think there is a sound recorder that is not also a sound player.
The overlap is no problem and I explained in detail for several Blends:
We do not want to build an exclusive categorisation which might be hard
to understand for our users. The important thing is to support our
users. A specific user wants to solve a certain task (and thus installs
a certain metapackage). The question whether some Dependencies are
also mentioned in a different metapackage is completely useles for this
task. So in fact we do *not* build a categorisation tree but build
pools of useful software for certain tasks which can definitely have
overlaps.
To come back to your example: A user who is seeking for his optimal
sound player is not served best if we "hide" an application from his
view by including it into sound recorders exclusively. While chances
might be good that a sound recorder is not as lightweight as a pure
player the user will find out this quickly if he is looking for only
a lightweight player - but perhaps he becomes happy later about the
"added value" of his favourite player if it also is able to record
sound.
I think I have to include this into the Blends doc somewhere ...
I agree that it makes sense, at least for some users. However, maintaining a
Blend is (I assume) time consuming.
It depends: Look for instance at the software page of the Debian
Accessibility project[1]: This page existed for a long time (BTW,
with Debian Med we started with something like that as well and learned
that maintaining such static pages is really hard). They were a perfect
preparation to enable me to generate the tasks files in 15 minutes
and some further work was done by Samuel Thibault (who is actually
member of the project) which all in all did not took him much more
than the same time to add some new projects. The result can be seen
here in the tasks[2] and bugs[3] pages. IMHO this time is quite well
spend for the result that you gain the following advantages:
1. General overview over your work
2. Translations of the descriptions of the package (do you think
that multimedia artists all over the world are perfect in
English?) If there are no translations an easy way to let
experts translate the descriptions and the whole Debian project
will profit from it
3. QA measures:
- The entries often contain "Homepage not available" links.
If you find these you immediately see the packages which were
probably not touched for a long time because the maintainer
missed to set the homepage field.
- See imediately problems in your descriptions etc.
4. Developer related overview about all packages that might concern
your work
Moreover you might register a page for ddpo for your group as I did for
instance for Debian Science[4]. All this becomes immediately available
"for free" updated twice a day in a cron job once you took the work of
just giving your packages some structure in the tasks files. And giving
your tasks some structure might make sense anyway. If you have some
concerns about editing the tasks files you might start laying out the
categories in a Wiki (Debian Science started like this) and I volunteer
to move this to tasks files to hand you over perfectly working examples.
It worked that way for Debian Science, Debian Accessibility and Debian Lex.
What I'm wondering is if it is worth the effort.
Don't ask me - I'm biased. I learned the advantages. You might also
profit from future developments which become available immediately for
all Blends.
Is it going to ease our work as a team?
Well, running a Blend has two parts: The technical part I explained above
and *forming a team*. Yes, definitely I regard a Blend not only as a
bunch of developers uploading packages but as a strongly connected team.
I learned that it is easier to form a team if you have a convincing and
visible structure. So several members of the Debian Med team actually
became involved because there were people who were actively working on
the same topic as them. So if you can easily present (advertise?) what
you actually have on a central place like the tasks pages you have
better chances to get newcomers involved. In 2003, when the Blends
effort started (at this time known as CDD) Free Ekanayaka who was working
at this time in the Agnula project was in big favour of it. I have not
heard from Free for a long time - but you will surely know him from
Debian Multimedia.
Is it going to make it easier for 64studio to integrate with us?
And finally you are approaching the global strategic idea of Blends.
There is no guarantee - but yes, this actually was one of my initial
ideas: Make Debian in itself attractive enough for specialists (here
multimedia artists) so that deriving from Debian just does not make
any sense. I have several Debian forks for certain user groups seen
raise and fall. My idea is that Debian is strong enough not to fall
so the best idea is to integrate your work. One of my most important
slides which I had on a talk in October 2002[5] (at this time all the
framework stuff did not existed and Debian Med was covered under
Debian Internal Projects) said in the end:
→ Basic idea: Do not make a separate distribution but make Debian
fit for special purpose instead
If you would like to take your time and browse through all my talks
you will find variants of this slide in every talk regarding this
topic. You know all the Debian derivatives regarding Multimedia
much better than me. My suggestion is: Just do the coding allways
inside Debian. Stay compliant to Debian policy and stick to the
DFSG. If you want to sell a product with your Branding (like
Studio64 or whatever) just create your installation Medium from
pure Debian (in the case of multimedia some non-free packages might
need to be added - or not) and than release your product which is
based 100% Debian. A 2-5 man company will have a much harder time
to survive if they try to do all the work which is just done inside
Debian over and over again instead of following the strategy I
suggested.
Kind regards
Andreas.
[1] http://www.debian.org/devel/debian-accessibility/software
[2] http://blends.alioth.debian.org/accessibility/tasks/
[3] http://blends.alioth.debian.org/accessibility/bugs/
[4] http://qa.debian.org/developer.php?login=debian-science-maintainers@lists.alioth.debian.org&ordering=3
[5] http://people.debian.org/~tille/talks/200210_lux_internal/index.html#page7
[6] http://people.debian.org/~tille/talks/
--
http://fam-tille.de
Reply to: