Re: Debian Multimedia Blend (Was: Defining interesting multimedia tasks)
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)
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)
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)
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)
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)
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)
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)
[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)
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)
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
Re: Defining interesting multimedia tasks
On Mon, Aug 23, 2010 at 12:01:30PM +0200, Reinhard Tartler wrote: > > 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. Do you mean the information is missing on the long list[1] (version information it is there on the detailed list)? What exact Link you have with "package documentation" in mind? > the ubuntu help wiki implements b) by linking to the upstream online > user manual or similar if available. The only source of information about upstream in a Debian package is currently the Homepage field. However I see a chance to establish something like you are suggesting if we would add a field to upstream-metadata.yaml[2] of each releavnt package. Charles Plessy and me are currently working on moving this information into Ultimate Debian Database (UDD - the web sentinel page is created from the information in UDD). So if it becomes consensus in Debian Multimedia to use this file we can fix this (no package upload should be needed because Charles has implemented a way to read the file from packaging Vcs). Kind regards Andreas. [1] http://blends.alioth.debian.org/multimedia/tasks/packagelist [2] http://wiki.debian.org/UpstreamMetadata -- 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: Defining interesting multimedia tasks
On Mon, Aug 23, 2010 at 11:14:06 (CEST), Andreas Tille wrote: > On Thu, Aug 19, 2010 at 01:18:47AM +0200, Alessio Treglia wrote: >> On Wed, Aug 18, 2010 at 10:02 PM, Reinhard Tartler >> wrote: >> > I particularily like >> > https://help.ubuntu.com/community/UbuntuStudio/Applications, which is >> > linked from the PackageList page! >> > >> >> We should write a similar page for summarize all available applications. > > I'm not sure that the time which is needed to write such Wiki pages is > 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 ubuntu help wiki implements b) by linking to the upstream online user manual or similar if available. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Defining interesting multimedia tasks
On Thu, Aug 19, 2010 at 01:18:47AM +0200, Alessio Treglia wrote: > On Wed, Aug 18, 2010 at 10:02 PM, Reinhard Tartler > wrote: > > I particularily like > > https://help.ubuntu.com/community/UbuntuStudio/Applications, which is > > linked from the PackageList page! > > > > We should write a similar page for summarize all available applications. I'm not sure that the time which is needed to write such Wiki pages is 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). Kind regards Andreas. [1] http://blends.alioth.debian.org/multimedia/tasks/packagelist -- 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: Defining interesting multimedia tasks
On Wed, Aug 18, 2010 at 10:02 PM, Reinhard Tartler wrote: > I particularily like > https://help.ubuntu.com/community/UbuntuStudio/Applications, which is > linked from the PackageList page! > We should write a similar page for summarize all available applications. -- 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: Defining interesting multimedia tasks
On Wed, Aug 18, 2010 at 04:18:32PM -0400, Felipe Sateler wrote: On 18/08/10 15:57, Reinhard Tartler wrote: But what we could do is to identify user tasks. Then, instead of providing metapackages or tasksel files, we list all applications in debian that can fulfill the purpose of that task, and give recommendations for the 'best' application in that task. Well (as I have said a few times), I'm mostly interested in the nice pages generated by the blends web sentinel. If we manage to get reasonable tasks, the pages can serve as recommendations for that task. The first idea is probably implemented most easily with debtags, while for the second we could consider popcon data. This is an interesting approach... but we loose the nice webpages (we would have to recreate them). I agree with Reinhart - and have tried selling debtags to Andreas before (but without backing it with code, so my argument was weak!). Debtags need not be double work: If we express "Multimedia" through facets in debtags, and tell Andreas the debtags commands to extract each of the "flavors" in our "Blend", then I am sure he will integrate debtags support for generation of those nice webpages - for the benefit of *all* Blends. - 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: Defining interesting multimedia tasks
On 18/08/10 15:57, Reinhard Tartler wrote: > On Tue, Aug 17, 2010 at 19:42:19 (CEST), Felipe Sateler wrote: > >> So, what are interesting multimedia tasks? I'm thinking: >> >> * audio production: sound synthesis, audio editing, sequencing. > > Does it makes sense to have each application installed? Maybe not all of them, but I think most people use more than one application for audio production. > >> * multimedia playing: vlc ;) > > While I think vlc is a very decent choice, I think it depends on the > used Desktop Environment. I'm not quite sure about the need of a multimedia playing task... all DEs have one or more media players. > >> * video production: ... I don't do this. > > There are some editing tools like avidemux, kdenlive, etc. > >> * home multimedia center: xmbc/mediatomb style software. > > Is that really a task? You generally want only one media center > installed, no? Yes. But (and I don't know about this) one would probably want a set of software installed together in a media center, not just xmbc or mediatomb. > > > But what we could do is to identify user tasks. Then, instead of > providing metapackages or tasksel files, we list all applications in > debian that can fulfill the purpose of that task, and give > recommendations for the 'best' application in that task. Well (as I have said a few times), I'm mostly interested in the nice pages generated by the blends web sentinel. If we manage to get reasonable tasks, the pages can serve as recommendations for that task. > > The first idea is probably implemented most easily with debtags, while > for the second we could consider popcon data. This is an interesting approach... but we loose the nice webpages (we would have to recreate them). -- 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: Defining interesting multimedia tasks
On Wed, Aug 18, 2010 at 18:29:39 (CEST), Alessio Treglia wrote: > On Wed, Aug 18, 2010 at 6:23 PM, Andreas Marschke > wrote: Or should we have a finer grained split? >> See element the Ubuntu based distro: >> http://www.elementmypc.com/ >> I think if you do a blend lets make it so people like them can get attracted >> to it. > > We may get and adapt some ideas from UbuntuStudio project, too: > > https://wiki.ubuntu.com/UbuntuStudio/PackageList > http://packages.ubuntu.com/search?keywords=ubuntustudio I particularily like https://help.ubuntu.com/community/UbuntuStudio/Applications, which is linked from the PackageList page! -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Defining interesting multimedia tasks
On Tue, Aug 17, 2010 at 19:42:19 (CEST), Felipe Sateler wrote: > So, what are interesting multimedia tasks? I'm thinking: > > * audio production: sound synthesis, audio editing, sequencing. Does it makes sense to have each application installed? > * multimedia playing: vlc ;) While I think vlc is a very decent choice, I think it depends on the used Desktop Environment. > * video production: ... I don't do this. There are some editing tools like avidemux, kdenlive, etc. > * home multimedia center: xmbc/mediatomb style software. Is that really a task? You generally want only one media center installed, no? But what we could do is to identify user tasks. Then, instead of providing metapackages or tasksel files, we list all applications in debian that can fulfill the purpose of that task, and give recommendations for the 'best' application in that task. The first idea is probably implemented most easily with debtags, while for the second we could consider popcon data. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Defining interesting multimedia tasks
On 18/08/10 12:56, Jonas Smedegaard wrote: > On Tue, Aug 17, 2010 at 01:42:19PM -0400, Felipe Sateler wrote: >> So, what are interesting multimedia tasks? I'm thinking: >> >> * audio production: sound synthesis, audio editing, sequencing. >> * multimedia playing: vlc ;) >> * video production: ... I don't do this. >> * home multimedia center: xmbc/mediatomb style software. >> >> Or should we have a finer grained split? > > I don't want to be bikeshedding. > > I withdraw my suggestions. Do with them however you want. Well, the point of my post was basically to allow some bikeshedding :p. I only generally use sound synthesis software, so I don't think my split is sensible overall. -- 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: Defining interesting multimedia tasks
On Tue, Aug 17, 2010 at 01:42:19PM -0400, Felipe Sateler wrote: So, what are interesting multimedia tasks? I'm thinking: * audio production: sound synthesis, audio editing, sequencing. * multimedia playing: vlc ;) * video production: ... I don't do this. * home multimedia center: xmbc/mediatomb style software. Or should we have a finer grained split? I don't want to be bikeshedding. I withdraw my suggestions. Do with them however you want. - 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: Defining interesting multimedia tasks
On Wed, Aug 18, 2010 at 6:23 PM, Andreas Marschke wrote: >>> Or should we have a finer grained split? > See element the Ubuntu based distro: > http://www.elementmypc.com/ > I think if you do a blend lets make it so people like them can get attracted > to it. We may get and adapt some ideas from UbuntuStudio project, too: https://wiki.ubuntu.com/UbuntuStudio/PackageList http://packages.ubuntu.com/search?keywords=ubuntustudio -- 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: Defining interesting multimedia tasks
Hi felipe and team, No there really wasn't any reason. I'm awfully sorry :). Thats what happens when you try a different mail-client. For the rest this time(I hope this works): >> * audio production: sound synthesis, audio editing, sequencing. >> * multimedia playing: vlc ;) ** Video: miro , totem , iplayer(?) ** Audio: Amarok, Rhythmbox ,Banshee , mocp :D >> * video production: ... I don't do this. * video: openmovieeditor (simplistic) kdeenlive (like a PS for video) >> * home multimedia center: xmbc/mediatomb style software. ** Moovida/elisa(in case you haven't heard: it will be renamed back to elisa) ** freevo (?) ** XBMC (of course) >> >> Or should we have a finer grained split? See element the Ubuntu based distro: http://www.elementmypc.com/ I think if you do a blend lets make it so people like them can get attracted to it. > Cheers, Andreas Marschke. On Tue, Aug 17, 2010 at 06:09:52PM -0400, Felipe Sateler wrote: > Hi Andreas, > > Any reason you replied only to me instead of to the list? > > On 17/08/10 15:06, Andreas Marschke wrote: > > On Tue, Aug 17, 2010 at 01:42:19PM -0400, Felipe Sateler wrote: > >> So, what are interesting multimedia tasks? I'm thinking: > >> > >> * audio production: sound synthesis, audio editing, sequencing. > >> * multimedia playing: vlc ;) > > ** Video: miro , totem , iplayer(?) > > ** Audio: Amarok, Rhythmbox ,Banshee , mocp :D > >> * video production: ... I don't do this. > > * video: openmovieeditor (simplistic) kdeenlive (like a PS for video) > >> * home multimedia center: xmbc/mediatomb style software. > > ** Moovida/elisa(in case you haven't heard: it will be renamed back to > > elisa) > > ** freevo (?) > > ** XBMC (of course) > >> > >> Or should we have a finer grained split? > > See element the Ubuntu based distro: > > http://www.elementmypc.com/ > > I think if you do a blend lets make it so people like them can get > > attracted to it. > > ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Defining interesting multimedia tasks
On Tue, Aug 17, 2010 at 09:19:21PM -0500, Romain Beauxis wrote: Le mardi 17 août 2010 13:44:01, Jonas Smedegaard a écrit : >Or should we have a finer grained split? I imagine something like this: * multimedia-gtk (enhancing e.g. gnome) * multimedia-qt (enhances e.g. kde) * multimedia-light (enhances e.g. lxde and xfce) * multimedia-tiny (enhances e.g. libphone-ui-shr) * multimedia-pro-audio * multimedia-pro-video * multimedia (recommending all of above) multimedia-streaming ? Yes! -- * 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: Defining interesting multimedia tasks
On Wed, Aug 18, 2010 at 08:52:56AM +0200, Fabian Greffrath wrote: Am 17.08.2010 23:54, schrieb Jonas Smedegaard: * multimedia-gnome (provides multimedia-playback; depends on Qt/Phonon-based and KDE apps) That's most probably wrong! Yeah, silly me - you know what I meant. - 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: Defining interesting multimedia tasks
Am 17.08.2010 23:54, schrieb Jonas Smedegaard: * multimedia-gnome (provides multimedia-playback; depends on Qt/Phonon-based and KDE apps) That's most probably wrong! ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Defining interesting multimedia tasks
Le mardi 17 août 2010 13:44:01, Jonas Smedegaard a écrit : > >Or should we have a finer grained split? > > I imagine something like this: > > * multimedia-gtk (enhancing e.g. gnome) > * multimedia-qt (enhances e.g. kde) > * multimedia-light (enhances e.g. lxde and xfce) > * multimedia-tiny (enhances e.g. libphone-ui-shr) > * multimedia-pro-audio > * multimedia-pro-video > * multimedia (recommending all of above) multimedia-streaming ? Romain ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Defining interesting multimedia tasks
Am Dienstag, den 17.08.2010, 13:42 -0400 schrieb Felipe Sateler: > * home multimedia center: xmbc/mediatomb style software. I'd suggest to distinguish between client and server tasks for software that is typically used in homes/families. There's typically one or more client machines that have to do the media playing and, if there's any "family server" around, that machine has to do the media serving tasks. signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Defining interesting multimedia tasks
On Tue, Aug 17, 2010 at 06:17:18PM -0400, Felipe Sateler wrote:
On 17/08/10 17:54, Jonas Smedegaard wrote:
* multimedia (depends on multimedia-gtk | multimedia-playback)
* multimedia-gnome (provides multimedia-playback; depends on
Qt/Phonon-based and KDE apps)
* multimedia-gtk (provides multimedia-playback; depends on
GTK/GStreamer and GNOME apps)
* multimedia-light (provides multimedia-playback; depends on
apps _not_ linked against desktop-homogenizing libraries)
* multimedia-tiny (provides multimedia-playback; depends on
apps targeted embedded devices)
I believe that each DE will have installed it's own media player. Is
there really a need for multimedia-{gnome,kde,gtk} tasks?
ok.
I was imagining that there was more to it than a "media player", but
thinking more about it I cannot come up with a sensible split: Those
(like me) favoring MPD will cherry-pick based on that. No point in
trying to group media players - they are either catch-all integrated
with a desktop or aiming at something specific which you then have a
specific interest in.
* multimedia-pro-studio (depends on "classic" GUI style
production tools like Ardour, JACK and Hydrogen)
* multimedia-pro-live (depends on production tools designed
for live mixing of audio and video)
* multimedia-pro-devel (depends on scripting and programming
tools like PureData and CSound)
While I know that the tasks are not meant to be disjoint sets, I think
that this split has too much overlap. In particular, both csound and
puredata can be (and are frequently) used for live coding, and I
suspect all sound programming languages can be too. So
multimedia-pro-devel would be contained within multimedia-pro-live.
Or maybe it is something else you are splitting on and I'm just
confused by the names?
Do any of us developers actually use e.g. VJ'ing tools?
I have the impression that those performing favor different tools than
those e.g. composing electronica. And that both camps typically use not
a single tool by a range of them together. I might be totally wrong.
I am well aware that each user has a personal favorite setup. We cannot
serve all. Skolelinux also do not serve all needs schools _can_ have,
but offer an easy way to install a sensible system (which happen to be
KDE-based, which I personally dislike).
- 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: Defining interesting multimedia tasks
On 17/08/10 17:54, Jonas Smedegaard wrote:
> On Tue, Aug 17, 2010 at 09:09:12PM +0200, Adrian Knoth wrote:
>> On Tue, Aug 17, 2010 at 08:44:01PM +0200, Jonas Smedegaard wrote:
>>
* audio production: sound synthesis, audio editing, sequencing.
* multimedia playing: vlc ;)
* video production: ... I don't do this.
* home multimedia center: xmbc/mediatomb style software.
Or should we have a finer grained split?
>>>
>>> I imagine something like this:
>>>
>>> * multimedia-gtk (enhancing e.g. gnome)
>>> * multimedia-qt (enhances e.g. kde)
>>> * multimedia-light (enhances e.g. lxde and xfce)
>>> * multimedia-tiny (enhances e.g. libphone-ui-shr)
>>
>> I cannot make qualified comments on these, but I somehow feel that
>> only eduacted users care about their widget library and/or desktop
>> environment. For everyone else, the distinction between GTK and QT and
>> even light and tiny is hardly obvious.
>>
>>
>> But let's talk about the main point I want to cover:
>>
>>> * multimedia-pro-audio
>>> * multimedia-pro-video
>>> * multimedia (recommending all of above)
>>
>> While I could perfectly live with the first two, the latter is
>> probably not the best choice: users could tend to read "Multimedia?
>> Cool, give me all." and end up with tons of software that's completely
>> inappropriate for them. They'll be facing a question about jackd
>> realtime priorities and probably more pro stuff.
>>
>> OTOH, producers might not want each and every single GTK+QT+whatever
>> movie player, desktop tool and the lot when installing a video editing
>> machine or digital audio workstation.
>>
>> Long story short: don't make a catch-all choice across consumer and
>> producer variants.
>
> Good point.
>
> Let me try again:
>
> * multimedia (depends on multimedia-gtk | multimedia-playback)
> * multimedia-gnome (provides multimedia-playback; depends on
>Qt/Phonon-based and KDE apps)
> * multimedia-gtk (provides multimedia-playback; depends on
>GTK/GStreamer and GNOME apps)
> * multimedia-light (provides multimedia-playback; depends on
>apps _not_ linked against desktop-homogenizing libraries)
> * multimedia-tiny (provides multimedia-playback; depends on
>apps targeted embedded devices)
I believe that each DE will have installed it's own media player. Is
there really a need for multimedia-{gnome,kde,gtk} tasks?
> * multimedia-pro-studio (depends on "classic" GUI style
>production tools like Ardour, JACK and Hydrogen)
> * multimedia-pro-live (depends on production tools designed
>for live mixing of audio and video)
> * multimedia-pro-devel (depends on scripting and programming
>tools like PureData and CSound)
While I know that the tasks are not meant to be disjoint sets, I think
that this split has too much overlap. In particular, both csound and
puredata can be (and are frequently) used for live coding, and I suspect
all sound programming languages can be too. So multimedia-pro-devel
would be contained within multimedia-pro-live.
Or maybe it is something else you are splitting on and I'm just confused
by the names?
--
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: Defining interesting multimedia tasks
On Tue, Aug 17, 2010 at 09:09:12PM +0200, Adrian Knoth wrote: On Tue, Aug 17, 2010 at 08:44:01PM +0200, Jonas Smedegaard wrote: * audio production: sound synthesis, audio editing, sequencing. * multimedia playing: vlc ;) * video production: ... I don't do this. * home multimedia center: xmbc/mediatomb style software. Or should we have a finer grained split? I imagine something like this: * multimedia-gtk (enhancing e.g. gnome) * multimedia-qt (enhances e.g. kde) * multimedia-light (enhances e.g. lxde and xfce) * multimedia-tiny (enhances e.g. libphone-ui-shr) I cannot make qualified comments on these, but I somehow feel that only eduacted users care about their widget library and/or desktop environment. For everyone else, the distinction between GTK and QT and even light and tiny is hardly obvious. But let's talk about the main point I want to cover: * multimedia-pro-audio * multimedia-pro-video * multimedia (recommending all of above) While I could perfectly live with the first two, the latter is probably not the best choice: users could tend to read "Multimedia? Cool, give me all." and end up with tons of software that's completely inappropriate for them. They'll be facing a question about jackd realtime priorities and probably more pro stuff. OTOH, producers might not want each and every single GTK+QT+whatever movie player, desktop tool and the lot when installing a video editing machine or digital audio workstation. Long story short: don't make a catch-all choice across consumer and producer variants. Good point. Let me try again: * multimedia (depends on multimedia-gtk | multimedia-playback) * multimedia-gnome (provides multimedia-playback; depends on Qt/Phonon-based and KDE apps) * multimedia-gtk (provides multimedia-playback; depends on GTK/GStreamer and GNOME apps) * multimedia-light (provides multimedia-playback; depends on apps _not_ linked against desktop-homogenizing libraries) * multimedia-tiny (provides multimedia-playback; depends on apps targeted embedded devices) * multimedia-pro-studio (depends on "classic" GUI style production tools like Ardour, JACK and Hydrogen) * multimedia-pro-live (depends on production tools designed for live mixing of audio and video) * multimedia-pro-devel (depends on scripting and programming tools like PureData and CSound) With "depends on" I really mean "depends, recommends or suggests, weighted how we consider a nice user experience. We can't (with current structures) serve all flavors of use equally well. but for each of the flavors we do serve well, we can suggest packages related to that flavor but deemed by us as overlapping and superfluous (which obviously means some other would favor those - else it had no point in being shipped with Debian at all!) Also, I do dream about being able in the future to serve more fine-grained needs, and we need to start somewhere to realize how clumsy our current mechanisms really are for serving things like this: Imagine in the future being able through debconf or similar to explress "I want to "edit video", mostly "live" on relatively "low-end hardware" using strictly "GUI" interfaces. - 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: Defining interesting multimedia tasks
On Tue, Aug 17, 2010 at 08:44:01PM +0200, Jonas Smedegaard wrote: >> * audio production: sound synthesis, audio editing, sequencing. >> * multimedia playing: vlc ;) >> * video production: ... I don't do this. >> * home multimedia center: xmbc/mediatomb style software. >> >> Or should we have a finer grained split? > > I imagine something like this: > > * multimedia-gtk (enhancing e.g. gnome) > * multimedia-qt (enhances e.g. kde) > * multimedia-light (enhances e.g. lxde and xfce) > * multimedia-tiny (enhances e.g. libphone-ui-shr) I cannot make qualified comments on these, but I somehow feel that only eduacted users care about their widget library and/or desktop environment. For everyone else, the distinction between GTK and QT and even light and tiny is hardly obvious. But let's talk about the main point I want to cover: > * multimedia-pro-audio > * multimedia-pro-video > * multimedia (recommending all of above) While I could perfectly live with the first two, the latter is probably not the best choice: users could tend to read "Multimedia? Cool, give me all." and end up with tons of software that's completely inappropriate for them. They'll be facing a question about jackd realtime priorities and probably more pro stuff. OTOH, producers might not want each and every single GTK+QT+whatever movie player, desktop tool and the lot when installing a video editing machine or digital audio workstation. Long story short: don't make a catch-all choice across consumer and producer variants. Just my €0.02 -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Defining interesting multimedia tasks
On Tue, Aug 17, 2010 at 01:42:19PM -0400, Felipe Sateler wrote: So, what are interesting multimedia tasks? I'm thinking: * audio production: sound synthesis, audio editing, sequencing. * multimedia playing: vlc ;) * video production: ... I don't do this. * home multimedia center: xmbc/mediatomb style software. Or should we have a finer grained split? I imagine something like this: * multimedia-gtk (enhancing e.g. gnome) * multimedia-qt (enhances e.g. kde) * multimedia-light (enhances e.g. lxde and xfce) * multimedia-tiny (enhances e.g. libphone-ui-shr) * multimedia-pro-audio * multimedia-pro-video * multimedia (recommending all of above) - 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
Defining interesting multimedia tasks
So, what are interesting multimedia tasks? I'm thinking: * audio production: sound synthesis, audio editing, sequencing. * multimedia playing: vlc ;) * video production: ... I don't do this. * home multimedia center: xmbc/mediatomb style software. Or should we have a finer grained split? -- 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
