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

Re: Publication information for tasks pages



Hi,

On Wed, Sep 02, 2009 at 08:43:10AM +0200, Andreas Tille wrote:
> in Debian Med we have started to add publication information to the
> tasks files.  

Nice.

However, at a quick glance, I only see "Please cite: " entries in the
task overview page, no further references, did I overlook something?

By the way, maybe it would be better and clearer to have that as "Cite
as: " rather, to send a bit stronger message that citing might not be
voluntary if you publish something (and might pre-empt complaints from
upstreams, dunno).

Apart from that, some more comments to the task overviews:

1. The screenshot thumbnails are unnecessarily small and the box they
are in has a big margin (at least on my 1024x768 gecko browser); I guess
that is a problem with screenshots.debian.net, but really - the
thumbnails are useless.  If they were twice as big, they would probably
still fit into the free space and be useful.

2. I know it's difficult, but I think it would be worthwhile to simpify
the version/arch table.  E.g. I am not sure arch information is needed
for all arches - maybe just scientifically interesting ones (i.e. mostly
i386, powerpc, amd64, ia64) or for a number of specifically tagged
packages where we think architecture information is actually important
(e.g. openmpi/other mpi implementation etc.).  In any case, I suggest to
use aliases for the architectures, like "Intel/AMD 32bit", "Intel/AMD
64bit" and "Intel Itanium" or so.  

3. Same goes for versions - maybe if the same version is available in
stable and testing (or unstable), only mention stable; maybe use
stable/testing/unstable (or even "Debian 4.0 (etch)", "Debian 5.0
(lenny)") instead of codenames (also note that codenames are sorted
alphabetically right now - sid is before squeeze).  Also, binNMUS are
displayed seperately - maybe it makes even sense to just show the
upstream version?

4. the java-script(?) pop-ups for tags and especially versions/arches
are a bit in your face.  I think having some extender-like facility
which dynamically extends the package's entry and displays the
information.

Following-up on the last though on 3. - did you consider having a
user-view and seperate developer-view?  The former could be simpler and
only show information a user might want (mainstream architectures,
upstream versions, etc.); whereas the developer view would show detailed
version information to diagnose e.g. missing or failed builds.


Sorry for this rather uncoherent brain dump...

Michael


Reply to: