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-multimedia@lists.debian.org as general > discussion list (for instance for discussion like this) for a Debian > Multimedia Blend and for an entry point of users to talk to the > package developers. This list has turned out to be a good success > in other Blends. > The reason to not to do so was that this list is used as packaging > list of DeMudi packages. > List Archive of August: 8 mails > List Archive of September: 1 SPAM mail > List Archive of October: 1 mail > In short: The mailing list is de facto free and really using it > might be a way to actively be notified about packages which are not > yet moved under pkg-multimedia-maintainers maintenance. So far Jonas is (I believe) the only one who opposes this split. I'm in favor, and if we do this we should announce it to devel-announce and -announce so that we can get some users there. What do others think? > > 2. The name > I'm in strong favour of DeMuDi because it is catchy and might be > known. This is the name for the blend? If so, I agree cannibalizing the DeMuDi name might be good. > > 3. The tasks > We had also a discussion about reasonable tasks[6]. I hereby want to > stress that my proposed task definitions[7] which are rendered here[8] > for a better overview are simply a suggestion of an uneducated multimedia > outsider. They are probably not very practical - but it is a task for > a multimedia expert and it should be *done* (not only discussed). If > you ask me, it should be done *before* Squeeze release. Even if we > will probably not able to release metapackages (we did not even decided > whether we want them at all - see below) - we can mention DeMuDi in the > release notes of Squeeze anyway. If not - we are simlpy missing a chance > to get attention of a wide public. I wholeheartedly agree with this. I will try to start modifying the tasks (they are a good base). I've added a new task, hopefully others can help too (I think we have too many, maybe we should merge some of them). > > 4. Metapackages > I'm in favour of creating metapackages because they have certain > advantages > and they at least do not harm. Those who do not like this stuff will not > install it - that's fine. As long as we don't have point 3, this one is moot. > > 5. Debtags > The DebTags technique should be used more heavily in Blends (see for > instance > [9]). I do not mind what comes first: Designing Debtags for multimedia > packages and proper debtagging for *all* relevant packages or defining > tasks, putting the packages in and use the tasks pages for enabling proper > DebTagging. IMHO the latter approach is more simple and can be easier > done. Once the DebTagging is done properly we might be able to decide > about means how to create tasks from DebTags. In any case we have to *do* > something - nothing comes from sit and wait. I don't really care much about debtags. They are inconsistent, little used and even less policed. > > That are my concerns about DeMuDi. I admit the point in time for such a mail > is not really well choosen because I'll be offline from tomorrow to 30. > October > (MiniDebConf in Paris). I'll give a Blends talk at this MiniDebConf and I > would like to say something about DeMuDi - I hope it will be more than this > kind of TODO list. There is at least one commit that is not by you now :p -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim=sbsfaaydnqmd3kofc1qwea9xvdnwrtofv...@mail.gmail.com
