[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ A ] [ B ] [ C ] [ next ]
The so called tasks pages probably give the most interesting overview about
what a Blend is actually doing for newcomers as well as a nice quality
assurance tool for developers. If you want to see examples for tasks pages
just have a look at the list
of all Blends
using this technique and follow the links to the tasks
pages once you selected one specific Blend.
If a Debian Pure Blend should be presented one of the first questions is, what packages are available. The next question might be which packages are on the todo list for inclusion in Debian to make Debian even more attractive for people the Blend is targeting at. Both questions can be answered if you point people to the dynamically created tasks page. The page is rebuild daily to stay up to date according to recent developments of the Blend. The build process works as follows:
Read dependency information of the tasks
files.
Verify whether there is really a package with this name and print the description of this package.
If there is no such package in Debian try to parse the tasks
file
whether there is some information given and mark the result as prospective
package for further inclusion.
The rationale behind this is to provide as much as possible information about packages that might be interesting for the target user of the Blend. Moreover the page can provide useful information for developers about things that might be a useful help for the project to work down the todo list and build Debian packages for software that is not yet included in Debian. To get the todo list builded it is necessary to add some additional information to the task files which are the main database of information for the Blend. The information is following the RFC822 syntax as all Debian control files do and is kept quite simple:
Even if there is no Debian package available for the moment the names of prospective packages are given as if they would exists. The rationale behind is that once such a package might exist the source of the metapackage does not have to be changed and will work out of the box after rebuilding.
The Ignore key should be the favourite way to use for specifying prospective packages in case the packages should be evaluated once it appears in the Debian package pool. If "Depends", "Recommends" or "Suggests" are used for not yet existing packages they will be turned into the list of Suggests of the metapackage and thus might be possible to become installed on a users machine if the user decides to install all suggested packages. If some evaluation should be done first the "Ignore" tag is your friend.
This is the URL to the software that should be packaged.
In case there might be a WNPP bug filed for this software the bug number is given here. This helps to keep track of the ongoing effort to package the software.
In case some developer claimed to care for the software (perhaps by issuing the WNPP bug report) the e-mail address of this developer is given here to enable an easy way to contact this person.
Debian cares always about the license. This information about prospective packages should be easily available.
If there is some Debian packaging stuff available this can be addressed in this field. Unofficial packages which have this field set are rendered in a separate section with links to the packaging SVN.
The usage for this field is the same as it is described in paragraph
6.2.5 of Debian developers reference
If there is some Debian packaging stuff available this can be addressed in this field. Unofficial packages which have this field set are rendered in a separate section with links to the packaging Git.
The usage for this field is the same as it is described in paragraph
6.2.5 of Debian developers reference
If there is some Debian packaging stuff available this can be addressed in this
field. Unofficial packages which have this field set are rendered in a
separate section above unofficial packages outside the official Debian mirrors.
If you have set Vcs-Svn
or Vcs-Git
there is no need
to set Vcs-Browser
explicitely because it is obtained
automatically from the other fields. But you might override this automatically
generated URL if needed.
The usage for this field is the same as it is described in paragraph
6.2.5 of Debian developers reference
In some cases there are unofficial packages for some software which are
prepared by a third party. It helps our users if they could install such a
package and thus the URL to it might be a helpful hint. This is also true for
developers because they might have a look at this packaging before they start
from scratch. Often packages are available at mentors.debian.net
and prepared by
people who do not yet have an official Debian maintainer status and thus are
not able to upload packages to the Debian mirror. The packages at mentors are
waiting for sponsoring of an official Debian maintainer and if such a package
shows up in the Blend tasks list it might speed up the inclusion into official
Debian distribution.
This tag should give reasonable information about the software as it normally
is done in debian/control
files. It can be either a copy of the
description of the WNPP bug or could be used to file a WNPP bug and thus helps
to simplify the packaging work.
In some cases it makes perfectly sense to add a remark on behalf of the Blends team to a package which is visible on the tasks page. This can be done using the Remark field. It can be used in the same syntax as a Description field in Debian control files.
Sometimes, specifically in the case of scientific software, the project authors ask for registration of their software to get numbers of users of their software. These numbers enable them to ask for further funding of their project. To support this intend of authors the tasks pages can feature a link to this registration page if the link is given in the tasks file in the Registration field.
Several scientific software asks users of the code to quote the publication
which was used to describe the algorithm. There was a really long discussion
on the Mailing list of
Debian Science Blend
(see the
start of the thread here
) how this might be approached. There was
some consensus that we need to define a general control file featuring the
citation information but the problem has no real solution in the near future.
To find an intermediate solution which solves the situation for the tasks pages
of Blends some Published-* tags can be inserted into the tasks
file which are rendered on the according tasks pages. Here comes a list of
these tags:
Authors of the publication. For consistency reasons it is suggested to use Firstname1 Lastname1, Firstname2 Lastname2.
Title of the publication.
URL with online infos of the publication. The title will feature a link to this URL - so please make sure there is a Published-Title field if you specify Published-URL.
Publication journal
Publication year
Any suggestion to enhance these fields is welcome.
To set some typical values for the web sentinel per Blend each Blend has to
provide a configuration file. These files are formatted in RFC822 files and
maintained
in SVN
. The following values can be set:
Id of the Blend (for instance debian-edu, debian-med, etc.)
Name the Blend in correct spelling. Please note that English spelling is without a dash and it is "Debian Edu" (not Debian-Edu) and Debian Med (not Debian-Med)
URL to technical information about the Blend
URL to the user oriented homepage of the Blend
URL of the Alioth project of the Blend (might be identical to ProjectUrl)
URL to a logo image of the Blend
E-Mail address of a mailing list where developers and users of the Blend are communicating
E-Mail address of a mailing list where developers of the Blend are discussing technical details of packaging
Directory where to put the rendered HTML pages. The Blends pages are hosted on
Alioth and usually stored at
/var/lib/gforge/chroot/home/groups/blends/htdocs/<ProjectName>
Directory where the rendering code stores temporary data like SVN checkout of
tasks files etc. This is usually set to
/var/lib/gforge/chroot/home/groups/blends/data/<ProjectName>
Path to tasks files in Blends SVN
/svn/blends/projects/science/trunk/<ProjectName>
In case a CSS file different from the default Blend CSS is wanted for a specific Blend a (relative) path to this file can be specified.
The Debian Description Translation
Project
(see Documentation packages, Section
6.1.5) provides users of non English languages with information about
Debian packages. The sense of supporting especially the translations of
descriptions which are in the focus of a Blend is to make the Blend even more
usable for our target users. Moreover people interested in the special field
of the Blend are most probably able to provide good translations if it comes to
texts that are specific to their field of knowledge. Thus there is a web page
automatically created that parses the tasks packages for package names and
verifies the translation status of the package descriptions.
Finally the DDTP descriptions are used to create internationalised pages of existing packages which might help users with insufficient skills in English to easily find their software of interest. If the browser locale is properly set the user will get translated descriptions of existing packages - provided that the DDTP translations for all these packages are existing.
For so called prospective packages - packages which are not yet in Debian as discussed above - only the information given explicitely in the tasks file can be provided. For official packages the Debian infrastructure provides a lot of metadata, that is collected in the Ultimate Debian Database (UDD). The script which is creating the web sentinel pages collects all this data from UDD and tries to provide the most comprehensive overview over a set of packages for a given task of a Blend. The following list gives an overview over the metadata of packages belonging to the tasks of a Blend.
If there is a DDTP translation the descriptions are translated.
The Homepage field is taken from the debian/control
file. If this
information is missing for some package on the tasks page it might be a sign
that the package is not properly maintained and deserves a wishlist bug report
to add this information (at least for non-native Debian packages.
Both are provides as mailto-links. If the latest Uploader is different from the Maintainer this information is given as well. This is specifically interesting for group maintained packages - actually a tendency in Blends to maintain packages as Blends team - where the maintainer is the Blends team and the Uploader is the name of the actual developer who uploaded the package.
The popularity contest database contains different values. The tasks page is presenting the most relevant of them: the number of people who really use this package regularly and the number of people who upgraded this package recently
A button can be used to uncover the versions of this package in the Debian package pool as well as the architectures for which this version exists. The button is coloures in yellow if there is a new upstream version available which enables the Blends packaging team to easily detect work items to do.
The goal of a Blend is to support their user as best as possible. So a feature
to have a quick overview about all packages in our focus might be helpful.
This is solved by the bugs overview page. To create this page the
tasks
files are parsed for the listed dependencies. Then the
Debian Bug Tracking System is consulted about known bugs of these packages.
All bugs are listed and marked with different colours according to their
severity. So the developers can easily check this page in case they plan to
fix some bugs that are relevant for the Blend.
If you want to see examples for those bugs pages just have a look at the
list of all Blends
using this technique and follow the links to the bugs pages once you selected
one specific Blend.
This page gives a recent overview about the current development activities of the Blend developers.
The Debian Quality Assurance group does a decent job in watching the status o f
Debian packages. If a package features a valid debian/watch
the
tool uscan
is able to verify the upstream source location for
newer versions. The QA report page reports issues about the packages that are
relevant for a Blend.
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ A ] [ B ] [ C ] [ next ]
Debian Pure Blends
14 November 2010tille@debian.org