Re: [Blends] Debian Games task files online
Hi Markus,
On Sat, Feb 01, 2014 at 10:40:07PM +0100, Markus Koschany wrote:
> Hi Andreas,
>
> thanks for your changes to the task files. I suggest we always use
> debian-devel-games for reaching a wider audience and getting some
> feedback since pkg-games-devel is simply a general bug mailing list and
> debian-games doesn't exist. :)
Got this (hopefully I remember next time).
> > Just `git pull` to get the changes (and check out the web pages linked
> > above). You might also be interested in the "thermometer" which gives
> > some overview about up to date versions:
> >
> > http://blends.debian.org/games/thermometer/
>
> That's a really nifty feature. I like it.
The page itself was invented by Debian GIS and I adapted it to use the
Blends tasks as input data. This is the kind of cooperation to create
common tools between Blends.
> > I could provide further help by running a script which is verifying
> > whether there are any packages maintained by Debian Games but not yet
> > mentioned inside the task (and thus may be falling through your sieve).
>
> Ok, here are some questions and explanations what I did and why.
>
> http://blends.debian.org/games/tasks/packagelist
>
> Based on the information provided by debtags, I created task files that
> correspond with each of the current game::* tags of the debtags
> framework.
I agree that DebTags provide a fairly reasonable input for
categorisation tasks. We discussed this here with people who want to
create an ontology about biological software and they were happy to be
told that DebTags exists and can be used ... provided they are
maintained properly which is (shame on the Debian Med team) not really
the case here.
> The result was that all games (not only those maintained by
> the Games Team) could be easily ascertained and grouped without having
> to know any further details about them.
While I was talking about packages maintained by Debian Games team but
not in the tasks pages I simply took the fact that there is for sure no
need to restrict the games tasks to those packages. The tasks concept
is explicitly for all and every package which fits into the scope of the
task (even if team maintenance is a thing that should be prefered for QA
reasons). The script I wrote was rather to be used by the Debian
Science team which is heterogen enough to include several package
maintainers who do not even know about the tasks framework. So I simply
wanted to have some control what these maintainers were doing and
whether everything ends up properly inside the tasks. That way I was
able to add more than 50 missing packages recently. Since I do not
assume that this is needed in Debian Games I just mentioned that this
kind of tool exist (without firing it up actually for checking).
> This approach is scriptable and
> easy to maintain and independent from human interactions.
>
> Two restrictions:
>
> 1. All games need an up-to-date and correct game::* tag.
> 2. If the tag is present, the information must be accessible/parseable
> somehow.
>
> If you compare all those category task files with the "main" task file
> (includes all binary packages in main of section games) and which will
> be visible tomorrow, you can see that some of the games are missing.
> That's because of 1 and 2. For example "freealchemist" was missing a
> game:: tag and "freeorion" is properly tagged but the information isn't
> accessible with the debtags command line tool.
What exactly do you mean by "not accessible with the debtags command
line tool"? In how far is this for some game different from other
games?
When I asked Enrico at last years DebConf how we could possibly join
DebTags into the Blends framework he did not even understood this
request. I just sumarised this by adding a new Q-A paragraph to the FAW
section of the Blends documentation:
http://blends.debian.org/blends/apd.html#DebTags
> How can I gain access to these information as soon as someone updates
> the relevant debtags for the game? UDD?
If you really stick to the DebTags idea UDD might be your friend. This
becomes even more true once the whole Blends framework might be migrated
to use UDD exclusively. Since last years GSoC project the metapackage
creation framework was ported from using tasks files directly to
creating the packages out of UDD information which has various
advantages. The thermometer feature you liked is a byproduct of this
effort which came pretty cheap since the tasks information is included
in UDD and I plan to rewrite also the complete web sentinel code
according to this. In UDD you have pretty easy access also to DebTags
so this would make a good fit (technically - my concerns from above will
remain).
> My intention is to let some kind
> of script run on a regular basis that spits out those task files. I
> assume we need to fix http://bugs.debian.org/709409 first?
Probably.
> The other advantage of properly maintained debtags for games is that we
> could come up with completely different task files in the future such as
> "action games written in Python", "only 3D or 2D games", "games with
> joystick support" etc. It would be tedious work, if this had to be done
> manually.
I agree on this part.
> How do other blend teams cope with the fact that packages get removed or
> introduced to the archive? Do they all revise their task files by hand
> again?
There is no need for revision. The tasks framework is checking the
available packages (and since the GSoC project it is creating
architecture dependant metapackages which are regarding the availablity
of the dependencies for the given architecture - but this is not yet in
production use and needs further testing).
> [...]
> > Please also tell me whether you
> > want to create metapackages and you need help with this. I'd be more
> > than happy to support this attempt.
>
> I'd be glad for any assistance in creating metapackages. Could you point
> me to the latest documentation, please?
I hope all questions will be answered in
http://blends.debian.org/blends
Any questiosn which need to better doc (preferably with patches as
usual) are welcome.
> I guess I need to catch up on
> some information here since Emmanouil did all this work last summer. I'm
> prepared to work on an implementation as soon as possible. Please feel
> free to respond to this mailing list or by opening new threads at
> debian-blends, I'm subscribed.
It's nice to know you are subscribed to debian-blends. I have put this
list in CC since it provides also some interesting general aspects. I
guess it makes sense to have people in Debian Games inside the discussion
even if they are not subscribed to the Blends list.
My suggestion is that for the next days you consider probably some fine
tuning + checking with your team mates on the tasks and if I'm lucky I
might get the first version of Emmanouils code uploaded (may be to
experimental for a first shot). Than we can try this.
> > Kind regards and greetings from Debian Med sprint in Stonehaven
>
> Have a nice weekend in Stonehaven. :)
It's a really cool (but also exhausting) meeting. Today I was showing
packaging at two random biological example packages at request of
participants. It was followed by five people who considered this an
imense help and they are right now working on their own packaging. I'd
strongle recommend adopting this kind of meetings.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: