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
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-multime...@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

  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 
     [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


[2] http://blends.alioth.debian.org/multimedia/tasks/packagelist
[5] http://wiki.debian.org/UpstreamMetadata
[8] http://blends.alioth.debian.org/multimedia/tasks/


pkg-multimedia-maintainers mailing list

Reply via email to