On 20.03.2013 11:45, Andreas Tille wrote: [...] >> Indeed two of my big goals are: >> >> 1. Creating a Live CD for games similar to the one from >> linux-gamers.net but using Debian instead of Arch Linux [1]. >> (A Blend) > > Properly designed metapackages could perfectly simplify the creation of > life CDs (using live-helper). > >> 2. A Debian Games Portal which pools all information about Debian >> games, screenshots, game descriptions (from the wiki) > > I'm sorry to interupt you - but why do you want descriptions from the > Wiki??? Didn't you write later that you want to have information in one > single place? We do have descriptions (and in several cases their > translations - number of these is constantly increasing) in the package > pool and you consider the Wiki for this purpose. Please consider our > experience from the past: I have mentioned these goals because i think Blend tools can help to achieve them. The reason why i also want to make use of Debian's wiki is simple. I think it is more efficient to use existing infrastructure which can easily harness the power of thousands of contributors who provide _additional_ information to a game or application. I think using existing package descriptions is an excellent idea, all the other things i mentioned are completely optional and can be added later step by step. [...] > I somehow have the feeling that you try to reach out in the direction of > NeuroDebian[2]. I will take a look. Thanks. > The people behind NeuroDebian are closely working > together with us and we are seeking for ways to create their web portal > based upon the information we are creating in the Blends framework (and > in turn enabling other Blends to profit from this work). I intent to > issue a GSoC project description about this at least at the end of this > weak. (If you are interested to influence this text you are well > advised to have a look at the debian-blends mailing list where I will > propose it for discussion first.) I will subscribe to debian-blends. [...] >> The Games Team is maintaining 331 source packages at the moment. I would >> prefer that contributors only need to enter information once but can use >> them multiple times. Would it be possible to create such pages out of >> debtag information and simply parse the information? If we want to >> create a metapackage which consists only of arcade games or if we want >> to update a task, couldn't we just make use of the information presented >> by debtags? > > First question: Are you pretty sure that those 331+x binary packages > are consistently and properly tagged? (I wrote 331+x binary packages > because there are more binary than source packages and DebTags as well > as tasks files are related to *binary* packages.) No, i'm not sure. The only reason why i have mentioned debtags was because i cannot really assess their relevance for Blends. I really want to avoid double work. Perhaps it might make more sense to add debtag information first and then create tasks from them automatically. On the other hand it might be easier to skip this step and to complete your tasks to get the job done. [...] > >> In my experience most Debian users don't even know about debtags > > +1 > >> and i >> struggle myself to find the right access to the topic. Most of the time >> as a user you don't need them, they are somehow opaque. > > Yes. But you decided to prefer DebTags over tasks to work on your goal > anyway. Why? I have no preferences so far and i'm undecided. Hence i'm curious to know what others on the list think about it. > As I said above I'm quite in favour of using DebTags in the Blends scope > but did not found a way how to do this. There are also other persons > who perfer DabTags - but from this mental preference we will not get > some product out. We need rather to work on it, right? [...] Skipping your six points here. You are making good points. For the sake of brevity: I agree with you that actually working on something is better than to talk the matter over and over again and reaching no consensus. Just give me more time to evaluate your proposals for myself. [...] >> I completely agree here. Promotion and new member recruitment are >> missing out somehow. I think your "Mentoring of the Month" project is >> admirable and all teams should do it. Even better Debian should start >> streamlining this process, > > Well, Debian is a Do-O-Cracy. So I'm doing it but you have no lever to > force other people to follow this example and to streamline this. Yes, > I agree it is worth copying but you can not say "Debian should adopt > this for their teams". "Debian is a Do-O-Cracy" together with "we are all volunteers" goes without saying. Unfortunately these buzz words are used too often when it would be more appropriate to say: Decision making is sluggish and we cannot reach a consensus. I think it's worth discussing this and to put more emphasis on team maintenance. I even think it would be great to write it down in Debian's policy. >> should encourage team maintained packages and >> simplify the packaging workflow by using only one Vcs (Git) and shaping >> the tools for it. > > I think this is done and Debian Games team is as far as I can observe > from the distant a good example for doing so. The Games Team has good documentation and i found it easy to follow it. Unfortunately other teams have done the same or they have different requirements. Hence my proposal to streamline this for all teams, because every team is part of Debian, isn't it? [...] > Do you have any better idea to change this rather than constantly > writing at mailing lists speaking at conferences (specifically DebConfs) > about his problem? I consider my DebConf talks as less crowded than > they deserve but there is no way to force people into it. On the other > hand I have never heard from anybody who has heard such a talk that is a > stupid idea and rather should be widely implemented. But there is the > known difference between *agreeing* to something an really *doing* > something for it. I think leading by example is the best approach. The other one is to reach a consensus and to anchor it in Debian's policy. I will read through the Blends documentation during the next days and give you more feedback about it. Would also like to see some improvements on this matter. Regards, Markus
Attachment:
signature.asc
Description: OpenPGP digital signature