[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:


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
    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


    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



Reply to: