#690414 PTS: screenshots related improvements

#690414#5
Date:
2012-10-14 04:45:30 UTC
From:
To:
For packages that have screenshots on screenshots.d.n, the PTS should
link to them so maintainers know about them and can review them.

It would also be good to have a todo item for packages that need a
screenshot, using various criteria such as debtags or dependencies.

#690414#12
Date:
2012-12-08 07:07:33 UTC
From:
To:
Christoph, I'd like to link to screenshots.d.n from the PTS. Would it be
possible for you to add per-source-package pages for the PTS to link to?

Also, do you think the PTS should do the checks for my suggested TODO
item or should that be done on screenshots.d.n?

#690414#17
Date:
2012-12-08 12:37:54 UTC
From:
To:
Believe it or not - I'm finally working on the web application behind
screenshots.debian.net. Slight delay of one year or something. :)
I had to fix a dependency module and was actually waiting for artistic
help from the Ubuntu project but I still don't have a good template.
So I'll hack something myself.

Am 08.12.2012 08:07, schrieb Paul Wise:

You mean where lookup is possible from the source package name instead
of the binary package name? Yes, that should work. I'll reflect that
in the database schema.
generalized list. Of course it can be implemented in the PTS but
screenshots.debian.net provides a list of packages with missing
screenshots anyway.

User-friendly version:
http://screenshots.debian.net/packages/without_screenshots

JSON version:
http://screenshots.debian.net/json/packages-without-screenshots

I could implement a certain URL returning information about
screenshots for a certain source package if that helps.

…Christoph

#690414#22
Date:
2012-12-08 13:22:55 UTC
From:
To:
Yeah, like the binary package page but listing all the binary packages
and their screenshots if any. Thanks.

Ok.

Well, we don't want a "Please upload a screenshot" TODO item on the PTS
pages of packages without any user interface or other screenshot-needing
part. For example some libraries provide a UI, others don't. Font
package screenshots are probably a good idea but packages containing
music/audio don't need screenshots. We need screenshots for games but
not really for game data packages. Screenshots for debug packages aren't
needed. Screenshots for metapackages could be interesting depending on
what they are. I think we need some heuristics for suggesting screenshot
uploading; based on package names, contents, dependencies and debtags.

#690414#27
Date:
2012-12-08 16:06:24 UTC
From:
To:
Am 08.12.2012 14:22, schrieb Paul Wise:

Indeed. Currently the software mainly uses debtags as heuristics to
determine if a package would be an interesting target for having
screenshots assigned. I'm open to ideas. After all the web site will
have to support other distributions (DEB or RPM) as well and I'm not
sure whether they have something similar to debtags.

…Christoph

#690414#32
Date:
2012-12-09 02:20:20 UTC
From:
To:
That sounds like a good start, are you exporting this list? We can make
adjustments to the heuristics as feedback comes in.

I'm thinking for the PTS side, we should have a todo item like this:

Your package probably meets the criteria for needing a screenshot, please upload one.

With "criteria" being a link to the human-readable explanation of the
heuristics and "upload" simply links source package page.

Even if they don't using distromatch, those other distributions can map
their packages to Debian packages and thus use debtags in some way.

#690414#37
Date:
2012-12-17 08:16:02 UTC
From:
To:
I've implemented the PTS side of this just now, how is the source
package page implementation going?

http://screenshots.debian.net/source/<srcpkg>

#690414#42
Date:
2013-01-24 11:53:30 UTC
From:
To:
I adjusted the implementation to work with the existing binary package
links and committed it to SVN. The next PTS update will have the links
but here are a couple of test cases:

http://packages.qa.debian.org/b/bzflag.html
http://packages.qa.debian.org/0/0ad.html

It would be nice to have this (would simplify the XSL), but I guess it
is blocked until debshots is converted from pylons to something else?

#690414#47
Date:
2013-01-24 17:29:49 UTC
From:
To:
Nice, thanks for that. One issue I see is that the pages on
<http://screenshots.debian.net> seem to reference and give information
about packages in Ubuntu (instead of Debian) which can be confusing for
users.

Regards,
Guillem

#690414#52
Date:
2013-01-24 21:19:32 UTC
From:
To:
Am 24.01.2013 18:29, schrieb Guillem Jover:

I'm aware that some packages may show that they are from Ubuntu while
they in fact used in both distributions. The reason is that
screenshots.debian.net was first created for Debian and then later
added packages that were only available on Ubuntu. The algorithm that
decides whether a package is shown as being in Ubuntu or Debian
doesn't make sense nowadays and will thus get a serious makeover. It's
just an ugly hack to support Ubuntu. Be assured that this will change.
In the future there will be screenshots.debian.net that prefers Debian
package information and screenshots.ubuntu.com that prefers Ubuntu
package information. The new version will also support other kinds of
Linux distributions like OpenSuSE and CentOS.

Cheers
 Christoph

#690414#57
Date:
2013-03-19 08:40:29 UTC
From:
To:
Would it be possible for you to export the results of those heuristics
to a machine-readable file for the PTS to read and use for suggestions?

#690414#62
Date:
2013-04-06 11:50:46 UTC
From:
To:
Don't expect too much. Basically it's a blacklist/whitelist thingy of
facets and tags. The current configuration is:
------------------------------ # Always import packages that have one of these tags # (overrides debshots.debtags_tags_blacklist) # role::whitelist helps whitelist "yelp" which is otherwise just # role::documentation debshots.debtags_tags_whitelist = made-of::font role::program x11::theme # Do not import packages that have one of these facets debshots.debtags_facets_blacklist = # Do not import packages that have one of these tags debshots.debtags_tags_blacklist = role::app-data devel::doc role::documentation role::source admin::kernel role::devel-lib role ::debug-symbols devel::library special::auto-inst-parts role::shared-lib # Do not assign tags to packages with these facets debshots.debtags_facets_ignorelist = scope special culture qa iso15924 # Do not assign these tags to packages debshots.debtags_tags_ignorelist = works-with::TODO ------------------------------ HTH, Christoph
#690414#67
Date:
2013-04-06 23:44:30 UTC
From:
To:
That is a good start, thanks. I'm now wondering how to sync the
blacklist and whitelist to the PTS. We could just initially copy and
munge it for PTS use, but it would be better to have an automated method
for doing that. Any thoughts? Perhaps a JSON export?

#690414#72
Date:
2013-05-20 21:24:40 UTC
From:
To:
Hi,

I was just pointed to this bug, since I was thinking about the presentation of
screenshots in the PTS. Thinking that it would be annoying to have missing
screenshots displayed as yet another todo item (pointless+annoying to too many
packages) I thought it might be better to link different: display a link if a
screenshot for a package exist. If the link is missing, its clear screenshots
are missing too.


cheers,
	Holger

#690414#77
Date:
2013-05-21 03:09:01 UTC
From:
To:
We already link to the screenshots page for binary packages:

http://packages.qa.debian.org/w/warzone2100.html
http://packages.qa.debian.org/b/bzflag.html

I still think it would be useful to display a todo item when a package
"should" have a screenshot but doesn't. We just need to work out the
right heuristics for that.

#690414#82
Date:
2013-05-21 08:24:14 UTC
From:
To:
Hi,

oh, cool, didnt notice.

yes, and a good one. That feature is burned after a period of too many false
positives...


cheers,
	Holger

#690414#87
Date:
2013-08-20 12:07:13 UTC
From:
To:
Hi,

Just a small note. Packages from non-free and contrib areas should be
filtered on the first step of check, because screenshots.debian.net does
not store data for them [1].

[1] http://screenshots.debian.net/about

Best wishes,
Boris