Re: Please consider maintaining Blends information (Was: Bullet Physics Library)
[Putting Debian Blends list in CC to enable wider discussion about DebTags]
On Wed, Mar 20, 2013 at 12:01:54AM +0100, Markus Koschany wrote:
> > Cool. Did you ever checked whether these games are properly mentioned,
> > classified and thus advertised to the public at the web sentinel of
> > Debian Games[1]?
>
> I know of Debian Blends, debtags and the attempt to create a Debian
> Games Live CD but i haven't added new information to the page yet but
> it's something which i find interesting to work on. More about possible
> reasons why it is neglected soon.
>
> 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: At first we had descriptions of what we are
packaging in Debian Med on the static HTML pages at www.d.o. When
realising that it becomes unmaintainable we started with Wiki entries
but despite the fame of Wikis to be up to date all the time we realised
that a) they are not and b) it requires way more work than expected.
As a consequence we invented the autogenerated tasks pages in the web
sentinel that IMHO perfectly qualify like the "Debian Games Portal" you
want to produce - at least if properly maintained. So far about the
main intention when implementing the web sentinel: It should serve as a
portal for each Blend enabling them to profit from the very same
technique.
> and debtag information.
Regarding DebTags see below.
> Combine that with the looks of a professional gaming
> clan homepage, add a forum, mumble and social networking and you get
> the big picture. Well, there is some work to do before... :-)
I somehow have the feeling that you try to reach out in the direction of
NeuroDebian[2]. 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.)
In general you are planing quite a big shot. IMHO it is a *very* good
idea to start with something existing first - for instance if you have
some ideas to tweak CSS or the template of the websentinel tasks pages -
this would come quite cheap. Adding other things later seems more
promising rather than doing everything from scratch (while refusing
something you can get for free).
> > The last changes on the games tasks files were done by
> > me (even if I'm not involved in Debian Games and thus perfectly
> > incompetent in categorising games) at 2011-11-27[2]. It would be really
> > great if somebody in the Debian Games team would consider having a look
> > at this effort which is really brain dead simple (just add a line
> >
> > Depends: <binary_package>
> >
> > to a file and be done - longer doc is available as well[3])
>
> I must admit i have to read the docs first but here are my thoughts:
>
> 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.)
Regarding the relation between DebTags and tasks: I'd really like to
merge both way closer and my first attemt to bring both approaches to
categorise binary packages together was to list DebTags on the tasks
pages for each package and explicitely invite visitors of the pages to
"go debtaging". I'd regard this as one option to get at least a very
basic tool to syncronise. Looking at the current tasks pages[3] the
binary packages mentioned there seem to be properly tagged but this is
IMHO just for historic reasons: When I started the Games tasks I was
simply lacking some knowledge about all the packages of Debian Games
team. My intention was to provide some kickstart but as I said in some
mails ([4],[5]) nobody honestly catched up with this. Due to the said
lack of information I simply used the games part once assembled by the
Debian Junior team. The Junior team has done some large effort in
synchronising DebTags and tasks - so this is the simple historic reason
why the currently available games inside the tasks are properly tagged.
It would be nice to learn more about: What tags exist for Games? Do
these match the current tasks? Why not simply change the tasks to match
the DebTags and put the dependencies in? The latter should be a
scriptable process if there is a way to get the outright list of games
related tags and the list of binary packages that are featuring these
tags.
> 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?
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?
>From my perceptions the current tasks have the following advantages:
1. I know that there are tools to install packages based on DebTags
but these are not widely known. So installing a metapackage is
quite transparent for users and you can easily tell them: Please
install games-arcade to get all arcade games inside Debian - that's
simple and easy to explain.
2. You have additional information about the categorisation inside
the metapackage description inside the tasks file and there is
an effectively working way to create those metapackages (using
blends-dev)
3. I consider the decision making process about the layout of the
different DebTags as I know it (may be it has changed) as longish
and not necessarily straightforward discussion on the DebTags list.
Creating a task is way more simple: You just create a file in
the Blends VCS (any DD has access other people need to become a
member of the Blends team) and you are done. This is from an
administrative view as simple as doing a Wiki edit (its just an
SVN and no Wiki ... will become a Git edit once Wheezy is released)
4. The tools you need to create web sites as you seem to have in
mind simply just exist for tasks files (and nobody took the effort
to do the same effort for DebTags).
5. The Blends tools also work for packages that are not yet inside
Debian - we can provide some kind of todo list featuring a current
status. If you might like to have a look at the Debian Med
Biology task[6] this feature becomes quite obvious. We can easily
list
Debian packages in New queue (hopefully available soon)
Packaging has started and developers might try the packaging code in VCS
and *all* the information is drained automatically from sources
available in UDD. There is no way to match this via DebTags because
you can only DebTag existing packages. I have no idea if this is
important for you - but we are working extensively with this feature.
In short: Current tasks based Blends tools can handle packages
right on our doorstep totally equivalent to the packages inside
Debian by simply using
Depends/Suggests: <binary_package>
whether it might be available inside the package pool, in the new
queue or as pure packaging code in VCS does not matter.
6. The tasks pages also are featuring sections:
Unofficial packages built by somebody else
No known packages available but some record of interest (WNPP bug)
No known packages available
which are currently manually injected into the tasks file (and in
case you might wonder why the WNPP-ed packages are not fetched
automatically: because nobody did the work yet)
You see that at least item 5. and 6. can not be implemented with DebTags
which is a clear sign that DebTags *alone* will not be the solution for
a wanted (at least by some Blends) feature.
> > IMHO it is your choice to tell the world:
> >
> > Hey, there are people inside Debian who care about Games / Multimedia
> > and we have all this cool stuff for you. Debian wants to be one of
> > the big distributions in this field.
>
> 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".
> 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.
> At the moment it appears to me every team reinvents
> the wheel over and over again, duplicate documentation (or none at all)
> and different package requirements contribute to the confusion.
Well, there is definitely some real life friction. My way to reduce
this friction is to propagate the Blends way. I admit my success is
quite limited - but you see: I'm working on this.
> The fact is, although the Games Team attracts in theory more users than
> Debian Med, i think your basic team work is better.
+1
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.
> It's kind of sad to
> see that Juhani's Neverball package with bugfixes got removed from
> mentors today because he couldn't find a sponsor in the past six months.
> As long as such simple things don't work, it will be hard to find people
> who want to work on the bigger picture.
That's correct - so I try to give technical support for simplifying the
task of presenting the big picture.
Kind regards
Andreas.
> [1] http://live.linux-gamers.net/?s=games
[2] http://neuro.debian.net/
[3] http://blends.alioth.debian.org/games/tasks/
[4] http://lists.debian.org/debian-devel-games/2011/09/msg00030.html
[5] http://lists.debian.org/debian-devel-games/2011/11/msg00047.html
[6] http://debian-med.debian.net/tasks/bio
--
http://fam-tille.de
Reply to: