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)
Hi all, shortly: On Tue, Oct 19, 2010 at 9:51 AM, Andreas Tille andr...@an3as.eu 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 ales...@debian.org 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 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)
On Tue, Oct 19, 2010 at 04:51, Andreas Tille andr...@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-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 to get attention of a
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 Wed, Oct 20, 2010 at 02:16:12PM -0300, Felipe Sateler wrote: On Tue, Oct 19, 2010 at 04:51, Andreas Tille andr...@an3as.eu 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)
On Wed, Oct 20, 2010 at 19:58, Jonas Smedegaard d...@jones.dk wrote: On Wed, Oct 20, 2010 at 02:16:12PM -0300, Felipe Sateler wrote: On Tue, Oct 19, 2010 at 04:51, Andreas Tille andr...@an3as.eu 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
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 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 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
