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
Attachment:
signature.asc
Description: This is a digitally signed message part.