Re: [Blends] Debian Games task files online
On Mon, Feb 03, 2014 at 03:47:32PM +0100, Markus Koschany wrote:
> That's also my understanding of the tasks concept. Although the Games
> Team maintains a fair amount of games, not all games in Debian are
> actually maintained by us. I think there shouldn't be any boundaries and
> users usually don't care about the fact who or which team maintains some
> piece of software. Hence I think games metapackages and the blends
> sentinel should reflect the current state of games in Debian as a whole.
On the other hand the information on the tasks pages has helped me a lot
to gather potential team members. It finally makes sense to integrate
maintainers actively into a fitting team. This has worked out quite
well for the Debian Med team.
> > 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).
> Thanks for mentioning this script.
> >> 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?
> Assuming you are running a sid based system and that you have updated
> your debtags cache by running "debtags update", you will see that
> freeorion is not listed as one of the strategy games, although it is
> properly tagged.
> debtags search game::strategy --names
> I presume the game is unreviewed by the debtags maintainers and then
> won't show up by using a debtags query.
Ahh, OK. Understand now. I think I remember that there is some
manpower bottleneck in the DebTags review. BTW, when I realised this I
think this is one more point in favour of manually edited tasks files -
but I really hope that this bottleneck can be solved since I regard
DebTags as an important feature.
> >> 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.
> If I could get access to debtags directly, I would prefer writing some
> kind of UDD query. The whole process of generating task files for games
> could and should be autogenerated on a server in my opinion. DebTags
> already provides a lot of useful additional information about games and
> I believe it is easier to convince people to update the debtags database
> than to motivate them to write task files by hand and check from time to
> time if they are up-to-date.
Would you mind discussing this also on the debtags devel list. As I
told you Enrico Zini is considering this as misuse of DebTags and I
think before you implement something like this it is worth discussing.
> > 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).
> I need to learn more about UDD first but I already like the general idea
> of creating all necessary information for blends by using this database.
> >> 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).
> That's a nice feature. So the tasks framework is also capable of
> "decrufting" task files?
Well, the content of the task files remains the same but the cruft does
not show up inside the metapackages and in the web sentinel. In the
logs of the web sentinel scripts you get some information about this.
Perhaps you like to have a look into #726492 where I reported this
problem to Debian Edu maintainers.
> (meaning detecting that a package once present
> in a task file was removed from Debian). But how do they cope with new
You need to add new packages to the tasks files (as you would also need
to DebTag new packages). I always propagate the very early injection of
new packages once they show up in Alioth VCS (we are parsing Git and SVN
of several teams including Debian Games).
> I assume since they only create tasks for their own team
> maintained packages, this might be a lot simpler for them, whereas games
> are maintained by various teams and single maintainers in Debian. (1096
> binary packages in main)
Do you know other teams directly targeting at Games where it would make
sense to parse the machine readable files in VCS?
Regarding maintaining the tasks files: Any DD has permission to edit
Blends tasks files - so you do not need to be a member of Debian Games.
> > 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.
> Sure. Feedback is welcome!