Debian Multimedia Blend (Was: Defining interesting multimedia tasks)
Andreas Tille
andreas at an3as.eu
Tue Oct 19 07:51:26 UTC 2010
Hi,
I'm trying to come back to a thread about a Multimedia Blend which was
started in August this year[1]. There was some discussion but no obvios
action. Yesterday I was able to do at least a bit of action *I* feel
able to do (and I do not feel able for the other parts). I try to
remember you hereby to some kind of todo list / somehow agreed upon
actions to bring the idea of a Debian Multimedia Blend foreward.
On Mon, Aug 23, 2010 at 12:01:30PM +0200, Reinhard Tartler wrote:
> > well spent. In the Blends approach we had done much efforts to maintain
> > lists of packages manually and all of them (explicitely those who were
> > Wiki based) just failed. It takes you much time to create such lists
> > and finally you will fail to keep them up to date. Thus we invented the
> > tasks pages including the long version (see example for Debian
> > Multimedia[1]) which was inspired by Ubuntu Wiki style. If you are
> > missing some information on the tasks pages please make some suggestions
> > what should be added (and how it should display).
>
> Well, the most obvious pieces of information missing are a) what version
> of the package is included in lenny and squeeze, and b) link to the
> package documentation.
The first missing piece of information ( a) versions in Lenny and
Squeeze) is solved now (see [2]). I agree that the layout is not nice -
it is just a prove that it was quite easy to do (about 15 lines of
code). The reason why I did not spend more effort in the layout is:
1) The long list of packages is rarely used by other Blends and Multimedia
has not shown enough interest to make me highly motivated to spend more
time.
2) It's quite simple to do for anybody, just change the template which
is available here[3].
I think a tabular design like
Package Shortdescription Version Lenny Version Squeeze
<Link pkg Homepage> <translated short desc> <version-link> <version-link>
woul be reasonable.
> the ubuntu help wiki implements b) by linking to the upstream online
> user manual or similar if available.
As I explained we just need to store this information somehow and as I
wrote in my previous response to this mail[4] (which remained unanswered
in mail as well as action) the solution I can see for this problem is
upstream-metadata.yaml[5]. If the information is *really* important for
you and you *really* want it to see it on the packages list of a
potential Multimedia Blend - just agree upon a fieldname (UpstreamDoc
comes to mind) and feed it into a debian/upstream-metadata.yaml in each
package which provides such information (remember: there is NO need for
uploading a package with this information - the file just needs to be
in packaging VCS).
Further problems discussed but unsolved (in no specific order):
1. Mailing list
I suggested to use debian-multimedia at lists.debian.org as general
discussion list (for instance for discussion like this) for a Debian
Multimedia Blend and for an entry point of users to talk to the
package developers. This list has turned out to be a good success
in other Blends.
The reason to not to do so was that this list is used as packaging
list of DeMudi packages.
List Archive of August: 8 mails
List Archive of September: 1 SPAM mail
List Archive of October: 1 mail
In short: The mailing list is de facto free and really using it
might be a way to actively be notified about packages which are not
yet moved under pkg-multimedia-maintainers maintenance.
2. The name
I'm in strong favour of DeMuDi because it is catchy and might be
known.
3. The tasks
We had also a discussion about reasonable tasks[6]. I hereby want to
stress that my proposed task definitions[7] which are rendered here[8]
for a better overview are simply a suggestion of an uneducated multimedia
outsider. They are probably not very practical - but it is a task for
a multimedia expert and it should be *done* (not only discussed). If
you ask me, it should be done *before* Squeeze release. Even if we
will probably not able to release metapackages (we did not even decided
whether we want them at all - see below) - we can mention DeMuDi in the
release notes of Squeeze anyway. If not - we are simlpy missing a chance
to get attention of a wide public.
4. Metapackages
I'm in favour of creating metapackages because they have certain advantages
and they at least do not harm. Those who do not like this stuff will not
install it - that's fine.
5. Debtags
The DebTags technique should be used more heavily in Blends (see for instance
[9]). I do not mind what comes first: Designing Debtags for multimedia
packages and proper debtagging for *all* relevant packages or defining
tasks, putting the packages in and use the tasks pages for enabling proper
DebTagging. IMHO the latter approach is more simple and can be easier
done. Once the DebTagging is done properly we might be able to decide
about means how to create tasks from DebTags. In any case we have to *do*
something - nothing comes from sit and wait.
That are my concerns about DeMuDi. I admit the point in time for such a mail
is not really well choosen because I'll be offline from tomorrow to 30. October
(MiniDebConf in Paris). I'll give a Blends talk at this MiniDebConf and I
would like to say something about DeMuDi - I hope it will be more than this
kind of TODO list.
Kind regards
Andreas.
[1] http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-August/011736.html
[2] http://blends.alioth.debian.org/multimedia/tasks/packagelist
[3] svn+ssh://svn.debian.org/svn/blends/blends/trunk/webtools/templates/packagelist.xhtml
[4] http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-August/012174.html
[5] http://wiki.debian.org/UpstreamMetadata
[6] http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-August/011950.html
[7] svn://svn.debian.org/svn/blends/projects/multimedia/trunk/debian-multimedia/tasks
[8] http://blends.alioth.debian.org/multimedia/tasks/
[9] http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-August/012031.html
--
http://fam-tille.de
More information about the pkg-multimedia-maintainers
mailing list