Hi \o Le 25/09/2019 à 13:46, Jonathan Carter a écrit : > Hey o/ > > I thought that it might be about time to start talking about plans for > bullseye. > > I'm just going to do a small brain dump here so feel free to add ideas > to this thread then we can create a wiki page for it.
Thanks for bringing that up ! > 1. Testing artwork > > Usually during a development cycle, debian testing has the same artwork > as stable, which can be really confusing to people especially when it > contains a version number. Isy Simpkins has created testing artwork that > we can use during testing to differentiate it from stable releases. > > Salsa: https://salsa.debian.org/rattusrattus/testingtheme-workinprogress I must say I’m not particularly fond of the artwork in its current form and would prefer to keep one of the former releases artworks already packaged. Besides, how/when do you intend to handle testing theme -> stable theme migration ? > 2. Final bullseye artwork > > To maximise the amount of time available to tweak and finish off the > final artwork, how about doing the wallpaper campaign drastically > earlier than in previous cycles? I was thinking between February and > July, choosing the final artwork at the end of July? That provides a lot > of time for someone to create artwork, and when it's chosen, a lot of > time for maintainers and for the artist to round everything off before > freeze occurs. Sounds good. > 3. desktop-base changes > > desktop-base now contains 7 themes, wouldn't it be better if the themes > were separated from the destkop base package? And then ideally, > desktop-base just recommends the latest theme, leaving it up to the user > to install any additional themes they might want to use or try out? Yes it’s been requested for some time and there’s even #681025 for that. > IMHO > it would be better if the themes had their own source package, creating > a binary package for every specific theme. Thoughts? In my experience it would make it much more difficult to make infrastructure change to the theme system (layout of files, use of alternatives…), and the last time I worked on this to put all elements from a given theme in the same folder I was glad to have existing themes around to update them. Also the « API » of the themes and what a new theme is supposted to provide to reasonably work is quite loosely defined and is currently only described in desktop-base’s README. So again putting other themes farther from desktop-base makes it more likely to end up with broken things. So I’m more in favor of keeping existing themes in the same repo if we’re willing to maintain them (I am). And dumping some more brain: 4. Plymouth It would be nice to have Plymouth: - activated by default on desktop installs -> requires someone to add "splash" to the kernel boot line - tested / fixed for lower bpp and text screen modes which from my last testing in a VM was not convincing. - switch themes with the rest of the theme pack Currently we have the desktop-theme alternative switching all other theme elements (grub, and the various desktops’ logins, wallpapers and lockscreens) in one operation, but it doesn’t do that for plymouth. My preferred solution is to handle Plymouth the same as other elements, meaning create a /usr/share/plymouth/themes/debian symlink to /usr/shar/desktop-base/active-theme/plymouth. It cannot work as is because plymouth checks that the parent folder containing the ${theme_name}.plymouth conf file matches ${theme_name} se having a symlink in place of a concrete folder breaks that. -> requires a patch in pymouth… TODO. :) Laurent, I’m copying you in case you want to chime in since we had discussions on that topic a couple of months/years back. 5. Improve the theme selection process Should we use a debconf question instead/in addition to the desktop-theme alternative ? Can we call update-initramfs / update-grub automatically after changing the theme selection this way ? Currently you need to manually call update-grub to update the grub theme and update-initramfs to update the plymouth theme after changing the desktop-theme alternative. How can we/should we replace the « dumb » calls to update-initramfs and update-grub in postinst with something more robust ? Should we use triggers for that ? This has been requested in #851893 because calling update-grub was causing issues in some situations and was more worked around than really fixed. Cheers, -- Aurélien -- -- Aurélien COUDERC Debian Developer
