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

Re: "desktop-base" for wheezy+1


[ 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 ]

	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
[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.

Reply to: