Plans for bullseye?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Plans for bullseye?

Jonathan Carter (highvoltage)-2
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.

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

Here are some screenshots where it is implemented so far, its
implementation is currently a work in progress:

Boot:

 * isolinux: https://i.imgur.com/xHOORft.png
 * grub: https://i.imgur.com/yp3IVjG.png

(yes, that's not very readable atm but that's fixable)

Calamares:

* https://i.imgur.com/k9PV3XV.png
* https://i.imgur.com/SibvLyh.png

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.

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? IMHO
it would be better if the themes had their own source package, creating
a binary package for every specific theme. Thoughts?

-Jonathan

--
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) <jcc>
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄⠀⠀⠀⠀  Be Bold. Be brave. Debian has got your back.

Reply | Threaded
Open this post in threaded view
|

Re: Plans for bullseye?

Paul Wise via nm
On Wed, Sep 25, 2019 at 8:03 PM Jonathan Carter wrote:

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

The ideas look 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?

Is there anything left in desktop-base if all the themes are removed?

> it would be better if the themes had their own source package, creating
> a binary package for every specific theme. Thoughts?

I like that idea, then we could have some more of the great themes we
had in release contests in the archive for folks to choose their
favourite among.

The idea has been discussed since 2008, some links:

https://wiki.debian.org/DebianArt/StructureThemePackage
https://github.com/ulrich-hansen/desktop-theme-kit

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

Re: Plans for bullseye?

Holger Levsen-2
In reply to this post by Jonathan Carter (highvoltage)-2
On Wed, Sep 25, 2019 at 01:46:33PM +0200, Jonathan Carter wrote:
> I thought that it might be about time to start talking about plans for
> bullseye.

sounds all good to me, thanks.


--
cheers,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [desktop-base] Plans for bullseye?

Aurélien COUDERC-4
In reply to this post by Jonathan Carter (highvoltage)-2
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

Reply | Threaded
Open this post in threaded view
|

Re: Plans for bullseye?

Aurélien COUDERC-3
In reply to this post by Paul Wise via nm
Le 25/09/2019 à 15:01, Paul Wise a écrit :

> On Wed, Sep 25, 2019 at 8:03 PM Jonathan Carter wrote:
>
>> 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?
>
> Is there anything left in desktop-base if all the themes are removed?

We also ship:
- debian logos/icons in various colors and resolutions
- the bits to make our themes the default in various places: gdm,
  gnome-shell, lightdm, xfce, kdm, plasma
- some useless .desktop files of Type=link pointing to various Debian web
  resources which all DEs I tested don’t recognise or handle in any way. :)

On the other hand:
grub-common looks for the active debian theme by itself by shipping
/etc/grub.d/05_debian_theme and suggesting desktop-base.

Plymouth explicitely selects the current buster theme futureprototype in
/etc/plymouth/plymouthd.conf


Cheers,
--
Aurélien