Debian Multimedia Blend (Was: Defining interesting multimedia tasks)

[Felipe Sateler]

On Tue, Oct 19, 2010 at 04:51, Andreas Tille <andreas at an3as.eu> wrote:
> 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.

I'm sorry about the lack of action, but I've had very little time
since this discussion was started.

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

I apologise again for having forgotten about this discussion.

> 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).

I find the blends approach much better than the wiki approach.

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

So far Jonas is (I believe) the only one who opposes this split. I'm
in favor, and if we do this we should announce it to devel-announce
and -announce so that we can get some users there. What do others
think?

>
>  2. The name
>     I'm in strong favour of DeMuDi because it is catchy and might be
>     known.

This is the name for the blend? If so, I agree cannibalizing the
DeMuDi name might be good.

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

I wholeheartedly agree with this. I will try to start modifying the
tasks (they are a good base).
I've added a new task, hopefully others can help too (I think we have
too many, maybe we should merge some of them).

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

As long as we don't have point 3, this one is moot.

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

I don't really care much about debtags. They are inconsistent, little
used and even less policed.

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

There is at least one commit that is not by you now :p

-- 

Saludos,
Felipe Sateler