Re: Debian Multimedia Blend (Was: Defining interesting multimedia tasks)

2010-11-03 Thread Felipe Sateler
On Sat, Oct 30, 2010 at 11:36, Andreas Tille  wrote:
> On Thu, Oct 28, 2010 at 08:34:38PM -0300, Felipe Sateler wrote:
>> Since we need to advertise this list, I think we should do a Bits From
>> our team. I have started a draft in
>> http://wiki.debian.org/DebianMultimedia/BitsFrom, so please add
>> anything you think we should be saying.
>
> That's a really good idea.  I have enhanced the Blends paragraph a bit.
> Once this bits are published I probably will unsubscribe the packaging
> list (so please at least CC me in Blends related subjects) and subscribe
> rather the general list.

Please, people, add whatever you think is important to the above wiki
page. In particular, I think the consumer side needs some real info in
there. Maybe Reinhardt or Fabian can add something there? All other
people are encouraged to add their view on what we have done too!

-- 

Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Debian Multimedia Blend (Was: Defining interesting multimedia tasks)

2010-10-30 Thread Andreas Tille
On Thu, Oct 28, 2010 at 08:34:38PM -0300, Felipe Sateler wrote:
> Since we need to advertise this list, I think we should do a Bits From
> our team. I have started a draft in
> http://wiki.debian.org/DebianMultimedia/BitsFrom, so please add
> anything you think we should be saying.

That's a really good idea.  I have enhanced the Blends paragraph a bit.
Once this bits are published I probably will unsubscribe the packaging
list (so please at least CC me in Blends related subjects) and subscribe
rather the general list.

Kind regards

  Andreas.

-- 
http://fam-tille.de

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Debian Multimedia Blend (Was: Defining interesting multimedia tasks)

2010-10-28 Thread Felipe Sateler
On Thu, Oct 21, 2010 at 18:20, Andreas Tille  wrote:
> On Wed, Oct 20, 2010 at 10:12:47PM -0300, Felipe Sateler wrote:
>> > Bugreports have been mentioned as an example of inappropriate mails for 
>> > such
>> > list, right? So what is then on-topic?  Is it for visions and metadesign -
>> > like a multimedia-specific d-project@ ?  Or is it more of a
>> > d-user-multimedia@ list?
>>
>> I would think of it more of a d-user-multimedia type of list than d-project.
>
> In Debian Med we have such a list which is open for user problems.  It
> is a good idea to involve users into discussion about tasks layout.
> Also the list is a good entry point for future developers who are just
> seeking a first contact.  The main issue is to form a community around
> the multimedia topic inside Debian.  Sometimes you can not predict what
> mails such a list might see.

Since we need to advertise this list, I think we should do a Bits From
our team. I have started a draft in
http://wiki.debian.org/DebianMultimedia/BitsFrom, so please add
anything you think we should be saying.

-- 

Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Debian Multimedia Blend (Was: Defining interesting multimedia tasks)

2010-10-21 Thread Andreas Tille
On Wed, Oct 20, 2010 at 10:12:47PM -0300, Felipe Sateler wrote:
> > Bugreports have been mentioned as an example of inappropriate mails for such
> > list, right? So what is then on-topic?  Is it for visions and metadesign -
> > like a multimedia-specific d-project@ ?  Or is it more of a
> > d-user-multimedia@ list?
> 
> I would think of it more of a d-user-multimedia type of list than d-project.

In Debian Med we have such a list which is open for user problems.  It
is a good idea to involve users into discussion about tasks layout.
Also the list is a good entry point for future developers who are just
seeking a first contact.  The main issue is to form a community around
the multimedia topic inside Debian.  Sometimes you can not predict what
mails such a list might see.
 
> > When we (apparently) lack the time already to do the technical work we would
> > like to, then where should the ressources come from to manage and care for
> > such a list?  Or do we simply provide the space and leave the Multimedia
> > users to discuss with themselves?
> 
> I would try to chip in when possible (it is much easier to answer a
> quick email than actually do work :p). But I would expect that, if
> there are multimedia users out there, soon they will start helping
> each other there.

+1

Kind regards

Andreas.

-- 
http://fam-tille.de

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Debian Multimedia Blend (Was: Defining interesting multimedia tasks)

2010-10-21 Thread Alessio Treglia
Hi all,

shortly:

On Tue, Oct 19, 2010 at 9:51 AM, Andreas Tille  wrote:
>  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.

+1 to the 'merge' action.

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

+1

>  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 already had a look and will try to adjusting them, there is
something I'd like to change.

>  4. Metapackages
>     I'm in favour of creating metapackages because they have certain 
> advantages
>     and they at least do not harm.

I agree, +1 to this too.

>  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 agree, again, and I think the second approach should be fine.


-- 
Alessio Treglia 
Debian & Ubuntu Developer | Homepage: http://www.alessiotreglia.com
0FEC 59A5 E18E E04F 6D40 593B 45D4 8C7C DCFC 3FD0

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Debian Multimedia Blend (Was: Defining interesting multimedia tasks)

2010-10-20 Thread Felipe Sateler
On Wed, Oct 20, 2010 at 19:58, Jonas Smedegaard  wrote:
> On Wed, Oct 20, 2010 at 02:16:12PM -0300, Felipe Sateler wrote:
>>
>> On Tue, Oct 19, 2010 at 04:51, Andreas Tille  wrote:
>>>
>>>  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.
>>
>> 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?
>
> Hmm.  Now that I reflect on it again, I am not so strongly against it,
> actually.  I see the point of better serving our users, but cannot help
> being sceptical still - so please help convince me:
>
> Bugreports have been mentioned as an example of inappropriate mails for such
> list, right? So what is then on-topic?  Is it for visions and metadesign -
> like a multimedia-specific d-project@ ?  Or is it more of a
> d-user-multimedia@ list?

I would think of it more of a d-user-multimedia type of list than d-project.

>
> When we (apparently) lack the time already to do the technical work we would
> like to, then where should the ressources come from to manage and care for
> such a list?  Or do we simply provide the space and leave the Multimedia
> users to discuss with themselves?

I would try to chip in when possible (it is much easier to answer a
quick email than actually do work :p). But I would expect that, if
there are multimedia users out there, soon they will start helping
each other there.

-- 

Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Debian Multimedia Blend (Was: Defining interesting multimedia tasks)

2010-10-20 Thread Jonas Smedegaard

On Wed, Oct 20, 2010 at 02:16:12PM -0300, Felipe Sateler wrote:

On Tue, Oct 19, 2010 at 04:51, Andreas Tille  wrote:

 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.


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?


Hmm.  Now that I reflect on it again, I am not so strongly against it, 
actually.  I see the point of better serving our users, but cannot help 
being sceptical still - so please help convince me:


Bugreports have been mentioned as an example of inappropriate mails for 
such list, right? So what is then on-topic?  Is it for visions and 
metadesign - like a multimedia-specific d-project@ ?  Or is it more of a 
d-user-multimedia@ list?


When we (apparently) lack the time already to do the technical work we 
would like to, then where should the ressources come from to manage and 
care for such a list?  Or do we simply provide the space and leave the 
Multimedia users to discuss with themselves?




 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.


I am a debtags fan.  Time will tell if I manage to back that up with 
action.  Exactly because it is (deliberately) vaguely policed, I guess 
there's no need for consensus on its use - those of us believing in its 
potential can simply start tagging to improve its usability :-)


Anyone interested but uncertain where to begin, please speak up, and I'd 
be happy to try explain how it works.


NB! There is absolutely no need to be a programmer or a Debian Developer 
to help improve debtags tagging!




Regards,

 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Debian Multimedia Blend (Was: Defining interesting multimedia tasks)

2010-10-20 Thread Andreas Tille
[Quick answere from Hotel in Sevillia]

On Wed, Oct 20, 2010 at 02:16:12PM -0300, Felipe Sateler wrote:
> 
> I apologise again for having forgotten about this discussion.

No problem - thanks for taking action now.
 
> > 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.

Me too. ;-)  Using upstream-metadata.yaml would make sense in any case.
 
> >     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?

Whatever we decide:  We should announce in any case the result.
 
> >  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.

Yes.  IMHO it was suggested by Free as name for the Blend in a past thread.
 
> 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).

I'm perfectly fine with any change you might do on the tasks layout.
The changes become effect on the tasks pages after the cron run (one per
day).
 
> I don't really care much about debtags. They are inconsistent, little
> used and even less policed.

While this probably describes the current state I think DebTags are a
good idea anyway.  If a Blends would be able to help for better DebTags
design this would be a good side effect.
 
> There is at least one commit that is not by you now :p

Great!

Thanks for working on this

 Andreas.

-- 
http://fam-tille.de

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Debian Multimedia Blend (Was: Defining interesting multimedia tasks)

2010-10-20 Thread Felipe Sateler
On Tue, Oct 19, 2010 at 04:51, Andreas Tille  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
>         
>
> 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-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.

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
> 

Debian Multimedia Blend (Was: Defining interesting multimedia tasks)

2010-10-19 Thread Andreas Tille
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 ShortdescriptionVersion Lenny   Version Squeeze


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