Hi [ Sorry to break the threading, but I'm following this through the mailing list archive and am not subscribed to this list; please keep me CC'ed for eventual follow-ups ]
On Tue, 10 Jul 2012, Paul Tagliamonte wrote:
[…]
> - Vote for a default theme (in a binding way) 2 months before freeze. This
> may
> consist of a list-wide vote, or perhaps a committee (at our dear DPL's
> discretion) of both primarily technical and primarily artistic folks. This
> way we can pick a theme that not only looks good, but is practical to
> implement in the timeframe given. The big changes to the theme shall be
> done
> with ample time before the freeze (a week at minimum) to ward off potential
> bugs. The idea here is to get the theme into the archive *before* a vote :)
[…]
As being somewhat familiar with switching themes in a Debian derivative
(aptosid[1]), I'd strongly suggest to aim for getting the agreed upon
themes packaged (even if not 100% final) and into the archive quite a
bit earlier than that. There are a lot of different packages and
maintainers affected and many usability issues (colour schemes, etc.)
won't get found immediately, so giving them some decent testing before
the freeze actually begins is usually needed[2].
Considering Debian's structure and diversity, I would suggest to target
getting an initial/ rough theme packaging (at least the colour scheme
should be considered final by then, details of the actual artwork can
get tweaked much longer) to be uploaded around three months in advance
to the announced freeze date, with the decision process happening
comfortably (6 weeks to 2 months?) before that. Doing the packaging as
a last minute job just puts a lot of stress on the packaging team and
enforces immediate attention from many affected, but not directly
related, package maintainers - while posing a large risk for usability
regressions late in the release process.
[ Unrelated to this, we are using split theme packages similar to the
newly proposed changes here, with generic meta packages for each
supported desktop environment[3] and alternate dependencies on the
current_theme[4] | virtual_package, while retaining support for past
release themes[5]. Technically we require SVG sources, which get
converted to their target format at package build time, for the
complete artwork, this keeps the packaging generic/ helps keeping
legacy themes updated with changing requirements for new desktop
environment/ display manager versions and makes licensing questions
easier ]
Regards
Stefan Lippers-Hollmann
[1] http://aptosid.com
[2] I once got handed over a wallpaper with large bright yellow parts,
which doesn't work well (read at all) with the general defaults of
of shadowless white font colours for desktop icons - the evening
before the final ISOs had to be delivered to the CD company…
[3]
http://svn.berlios.de/svnroot/repos/fullstory/aptosid-art-meta/trunk/debian/control
[4]
http://svn.berlios.de/svnroot/repos/fullstory/aptosid-art-thanatos/trunk/debian/control
http://svn.berlios.de/svnroot/repos/fullstory/gfxboot-themes-aptosid/trunk/debian/control
[5]
http://svn.berlios.de/svnroot/repos/fullstory/aptosid-art-legacy/trunk/debian/control
signature.asc
Description: This is a digitally signed message part.
