Something preliminary to show (Was: How important is "Architecture: any")
On Tue, 4 Mar 2008, Holger Levsen wrote:
Hey, don't blame me for you not knowing stuff ;-)
Why not? You should have noticed that I'm quite naive and so you should
have told me. ;-)))
Well, in how far it is _important_?
Ok, important was probably not right. But I consider "minor" wrong as well :)
I do so as well and I'm quite proud on the low bug number of my own
packages. On the other hand I do not care for _potential_ bugs as long
as actually no real bug occured I consider the time as safe to work on
a better solution.
It's a normal bug in Debian, that some architectures are not as well
supported as others. But I wouldn't call this minor, as one selling argument
of Debian is, that we support all archs equally well.
Well, if it makes sense. I'm not convinced that every application has
to be available from s390 to arm. It's a brave goal to support all
equally but its kind of academic and should not stop progress
at important fields.
Just for the record: After fixing some bugs in debian-edu tasks files
which were not compliant to RFC822 format it was easy to run the script
that generates the tasks pages. ATTENTION: This is not finished!!!
It just shows a raw sketch. There are some Debian-Med strings inside
ane probably other stuff:
http://cdd.alioth.debian.org/education/tasks/
Why am I posting half-brewn things?
Well, I'd like to collect some hugs for doing this job. ;-)
Honestly, there can be done some work by you people to get finished
at the same time when the script is working perfectly in a cron job.
These tasks are (those who often call themselves "pure users" - I
do not like this term - should read below the --------- line):
- Commenting on my plan to collect all the CDD tasks pages under
http://cdd.alioth.debian.org/CDD/tasks/
You can link / redirect from debian-edu.alioth.debian.org or
wherever. The rationale behind this is that factorising things
is much more fun if you can relay on a common layout. (BTW,
this will be done also at the cost of the current Debian-Med
pages which have to be moved as well.)
- Documenting the Tags you invented for the tasks files. Today
I learned about keys
'Architecture': meaning is clear, but do we really need this -
I guess having the same architecture (either 'all'
or 'any' should be OK, right)
'Avoid', 'Ignore': meaning not fully clear, especially what
is the difference?
'Leaf': meaning unclear
'NeedConfig': meaning unclear
'Note': What's the difference to the 'Why' key that is used
as 'just another comment'
'Section': meaning is clear, but I wonder whether it makes
sense to sort different meta packages in different
sections. I'm not against it, but I would like to
hear some hard reasons
I think most of these tags are not relevant for rendering the
tasks web pages - except perhaps if we want to add different
levels of comments (render either 'Why' or 'Note' as additional
comment to the description of a package might be some idea
that comes to mind.
The prefered way to document thosekeys would be to directly
edit the docs at
http://svn.debian.org/wsvn/cdd/cdd/trunk/cdd/doc/en/08_websentinel.sgml?op=file&rev=0&sc=0
Well, strictly speaking these tags have nothing to do with the
web sentinel and the doc should be restructured (feel free to
do so!) but at least there are some explanations of some other
keys used in tasks files.
- A very important task would be to teach all interested people
Norwegian to cope with the comments in Norwegian. Alternatively
you might translate the comments into English. :-)
----------------------------------------------------------------
Todo for enhancing the content of the tasks pages:
- Just proofread the pages.
- If you find some mistakes go to the bug page of the according package
and verify if this problem is reported. If not file a wishlist
bug report.
- A systematic problem is the "Homepage not available" string in the
header information and once you read the description of the package
there is a link to the homepage. The explanation is simple: Formerly
maintainers had to list homepage information in the description of the
package. Finally it was decided to use an official "Homepage" tag
in the control information. The script parses this tag exclusively.
While it would be cheap to parse the description for homepage
links I decided against this workaround. The rationale behind is
simply the fact, that packages which show this are either not touched
for a long time or the maintainer did an incomplete job. So I would
like to set a flag onto these packages. So if you detect a package
that has "Homepage not available" set proceed as described above: Go
to the bug pacge of this package, verify whether this bug is just
reported, file a bug report with severity minor (IMHO) against the
package. If you are a DD offer group maintenance!
- Check for group maintenance. The Debian-Med team tried to take over
any medicine related package into common maintenance. I agree that
the issue is harder in the Debian-Med team because a large amount of
packages is not only education specific. But it should be verified
for every single package whether it might be reasonable. The Debian-Med
group maintenance was a pure success!
Got your todo list ready? Then start now and lets see who finishes
first: I with finishing the scripts for all CDDs or you with your
QA work described above. ;-)
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: