Re: Blends pages, tasks pages etc.
Hi Paul,
Paul Wise <pabs@debian.org> writes:
> On Mon, Dec 7, 2015 at 3:58 PM, Ole Streicher wrote:
>> At least for astronomy, most of the packages are part of some framework:
>> Python, GDL, (ESO-) CPL etc. They usually have their user interface
>> through the framework, which is more or less independent of the packages
>> packages. For example, the CPL framework has ~12 plugins, and two user
>> interfaces: one command line (esorex) and two Python (python-cpl). The
>> Python interface is "import cpl; recipe = cpl.Recipe('muse_bias'). IMO
>> it does not make any sense to screen-shoot this somehow, and also not
>> the command line interface. Or do you have an other idea here?
>
> Screenshots of typical uses of command-line interfaces are useful IMO.
I was just browsing among several screenshots of command line
tools. Apart from a few which have a quite simple, visible output (like
reformat), many have just a screenshot of the manpage -- this shows that
there is no really useful screenshot of the program itself possible. But
if we consider a manpage having useful information here: why don't we
include its information directly in the package metadata?
Especially for science data, the command line usually just takes some
input files, processes them and creates an output file. What you *see*
there has nothing to do with the "usage" of the program itself --
sometimes (if the program creates images) one could use such an image (I
did this for astrometry.net), but the program output itself is
uninteresting.
And, you see absolutely nothing on the iconic view (f.e. on
packages.d.o, or the blends tasks pages).
> For Python code, less so since Python is rarely written interactively
> (I guess), but you seem to indicate that is common, so maybe they are
> useful.
For (many) scientists, Python is used heavily for interactive sessions.
There are ipython and jupyter-notebook especially for that (the latter
even with inline graphics). However, for a typical use the link to a
tutorial is much more helpful than a screenshot to get a first
impression.
>>> Debtags are definitely not obsoleted by AppStream.
>>
>> Then, I didn't uderstand you right here.
>
> They are completely unrelated, I'm sorry if I gave the impression that
> they were.
The https://wiki.debian.org/Debtags/FAQ states:
| What are future plans and perspectives?
| debtags is rather mature, and not much is expected to happen besides
| regular maintenance.
| If you are looking for exciting new work you can look at the
| Appstream project.
And I must say that I don't see a real-world use for them. For example,
the Blends package lists I am currently working on (wich is the origin
of all the discussion here) would be a perfect place to use this
information, or at least to display them in a nice form so that a user
could benefit from them. However: I have no other idea than just to
create a line "Tags" and plainly list them.
Horribly useless.
Andreas' Tasks pages also hide them in some tooltip; and they appear
there as well just as plain tags. In packages.d.o they are at least on
the main page, but also just as a plain list. I doubt this gives
anything to a non-geek end user.
Let's take two of my packages: esorex and astrometry.net. The first one
has debtags, the second hasn't. Can you point me to a /any/ place in the
Debian ecosystem where esorex benefits from its debtags, while
astrometry.net doesn't? Could you specify a use case that is currently
solved with the Debtags?
And, for some reason they are maintained completely separate from the
package (as is screenshots.d.o, BTW). When I create a package, I cannot
just put them in d/control (or have a nice debian-helper for the trivial
ones), there are no Lintian checks for them ("A package linked to the
KDE libs should have the uitoolkit::qt tag"), I have no maintainers
control over them (everyone can change/remove them), the debtags editor
is ugly etc.
This all is -- for a "matured" infrastructure -- not really overwhelming.
> Personally I'd be motivated to correct the mistake, no matter the
> circumstances.
In the past I had the debtags creation integrated somehow in my package
creation workflow -- although this was hard: I could not create my
package and, while everything is still fresh, create the tags, but I
had to wait until the package passed NEW. This may take some weeks or
even months; I am then already busy with other stuff, have to mentally
go back to the old package to create the tags. I did this for a while,
but then I realized that some of the tags got lost without that I can
see a reason -- then it starts to feel like a Don Quichotte fight.
Screenshots are similar: As long as I am working on the package
creation, I am quite close to the package; it would be easy to create a
screenshot and include it in the package itself. But this is not the way
to go; I even can't include the screenshot at this stage (since it is
not in Debian then). I have to wait until the package is accepted, and
even then I cannot always upload a screenshot (f.e. for python-yt it is
impossible). And, screenshots get lost without a reason. How shall I
"correct" this when the program is not of my daily use?
But if your motivation is high, feel free to help creating screenshots
and debtags :-) My isn't anymore :-(
Best regards
Ole
Reply to: