wayland issueshttps://gitlab.freedesktop.org/groups/wayland/-/issues2023-07-18T11:55:25Zhttps://gitlab.freedesktop.org/wayland/weston/-/issues/779Build error when xwayland is disabled.2023-07-18T11:55:25ZTomohito EsakiBuild error when xwayland is disabled.Disabling xwayland (use -Dxwayland=false option in meson) causes build errors.
I think this is caused by the following patch.
```
commit: 388702c181829a99b1540eeea734dc496f62f7f4
frontend: Explicitly destroy Xwayland from frontend code
`...Disabling xwayland (use -Dxwayland=false option in meson) causes build errors.
I think this is caused by the following patch.
```
commit: 388702c181829a99b1540eeea734dc496f62f7f4
frontend: Explicitly destroy Xwayland from frontend code
```
Ninja build log:
```
$ ninja -C build/
ninja: Entering directory `build/'
[27/83] Linking target compositor/libexec_weston.so.0.0.0
FAILED: compositor/libexec_weston.so.0.0.0
cc -o compositor/libexec_weston.so.0.0.0 compositor/libexec_weston.so.0.0.0.p/meson-generated_.._.._protocol_text-input-unstable-v1-protocol.c.o compositor/libexec_weston.so.0.0.0.p/meson-generated_.._.._protocol_input-method-unstable-v1-protocol.c.o compositor/libexec_weston.so.0.0.0.p/main.c.o compositor/libexec_weston.so.0.0.0.p/text-backend.c.o compositor/libexec_weston.so.0.0.0.p/config-helpers.c.o compositor/libexec_weston.so.0.0.0.p/weston-screenshooter.c.o -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libexec_weston.so.0 '-Wl,-rpath,$ORIGIN/../libweston:/home/etom/work/wayland/env/lib' -Wl,-rpath-link,/home/etom/work/wayland/src/weston/build/libweston -Wl,-rpath-link,/home/etom/work/wayland/env/lib shared/libshared.a libweston/libweston-13.so.0.0.0 /home/etom/work/wayland/env/lib/libwayland-client.so /home/etom/work/wayland/env/lib/libwayland-server.so /usr/lib/x86_64-linux-gnu/libpixman-1.so /usr/lib/x86_64-linux-gnu/libxkbcommon.so /usr/lib/x86_64-linux-gnu/libinput.so /usr/lib/x86_64-linux-gnu/libevdev.so -ldl -Wl,--end-group -pthread
/usr/bin/ld: compositor/libexec_weston.so.0.0.0.p/main.c.o: in function `wet_main':
/home/etom/work/wayland/src/weston/build/../compositor/main.c:4254: undefined reference to `wet_xwayland_destroy'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
```https://gitlab.freedesktop.org/wayland/weston/-/issues/778The mouse button release signal is not called after moving the surface2023-07-18T00:43:39ZHyomin KimThe mouse button release signal is not called after moving the surfaceAfter moving the surface, the button release signal is not called because move_grab_button and shell_grab_end don't transfer it to the client. Please refer to [the codes]. And same situation can be seen during resizing or rotating the su...After moving the surface, the button release signal is not called because move_grab_button and shell_grab_end don't transfer it to the client. Please refer to [the codes]. And same situation can be seen during resizing or rotating the surface. So the client doesn't know the mouse has been released.
There is an issue regarding this on chromium. [link]
Can I manage this issue by transferring the release signal from the shell_grab_end function?
[the codes]: https://gitlab.freedesktop.org/wayland/weston/-/blob/main/desktop-shell/shell.c#L1179
[link]: https://bugs.chromium.org/p/chromium/issues/detail?id=1432559&q=1432559&can=2https://gitlab.freedesktop.org/wayland/wayland/-/issues/395xwayland applications blurry and qt renders incorrectly2023-07-13T15:44:40ZNaim Chowdhuryxwayland applications blurry and qt renders incorrectlyI use wayland on my nvidia laptop on fedora gnome workstation 38, my main display is a 4k TV which the laptop is connected to via HDMI cable.
Applications that use the X11 windowing system are blurry, not rending at 4k, probably 1080p o...I use wayland on my nvidia laptop on fedora gnome workstation 38, my main display is a 4k TV which the laptop is connected to via HDMI cable.
Applications that use the X11 windowing system are blurry, not rending at 4k, probably 1080p or lower.
Additionally, applications that use the QT framework do not render correctly (example screenshot attached).
![image](/uploads/de14ffc89f007b6a063acc0dee7bfa17/image.png)https://gitlab.freedesktop.org/wayland/wayland/-/issues/396Computer hard crashes when TV goes to sleep2023-07-13T15:41:31ZNaim ChowdhuryComputer hard crashes when TV goes to sleepI use wayland on my nvidia laptop on fedora gnome workstation 38, my main display is a 4k TV which the laptop is connected to via HDMI cable.
When the TV goes to sleep, the computer hard crashes and I am forced to restart.I use wayland on my nvidia laptop on fedora gnome workstation 38, my main display is a 4k TV which the laptop is connected to via HDMI cable.
When the TV goes to sleep, the computer hard crashes and I am forced to restart.https://gitlab.freedesktop.org/wayland/wayland/-/issues/393Failed to start X Wayland: Directory "/tmp/.X11-unix" is not writable2023-07-11T17:26:36ZTimur ChernykhFailed to start X Wayland: Directory "/tmp/.X11-unix" is not writableSystem logs: [system-log-Tue_Jul_11_08_15_56_PM_MSK_2023.log](/uploads/532767d7f425568456be3180efe7d979/system-log-Tue_Jul_11_08_15_56_PM_MSK_2023.log)
Found related MR: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2096System logs: [system-log-Tue_Jul_11_08_15_56_PM_MSK_2023.log](/uploads/532767d7f425568456be3180efe7d979/system-log-Tue_Jul_11_08_15_56_PM_MSK_2023.log)
Found related MR: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2096https://gitlab.freedesktop.org/wayland/weston/-/issues/758Weston 12 rdp can't star visual studio code (electron)2023-07-11T15:48:28ZGianluca S.Weston 12 rdp can't star visual studio code (electron)I build weston 12.0.1 then I start weston with rdp backend
`"$WESTON_PATH/bin/weston" --backend=rdp-backend.so
--config="${SCRIPT_PATH}/weston.ini"
--logger-scopes=log,rdp-backend --port=8081 --rdp-tls-key="${WESTON_KEY}/tls.key" --rdp-...I build weston 12.0.1 then I start weston with rdp backend
`"$WESTON_PATH/bin/weston" --backend=rdp-backend.so
--config="${SCRIPT_PATH}/weston.ini"
--logger-scopes=log,rdp-backend --port=8081 --rdp-tls-key="${WESTON_KEY}/tls.key" --rdp-tls-cert="${WESTON_KEY}/tls.crt"`
* start visual studio code with wayland `code-insiders --enable-features=UseOzonePlatform --ozone-platform=wayland --verbose`
* **vscode starts, the process is running, but no windows is displayed**
* google-chrome with same arguments works in weston 12
* wezterm, weston terminal and flower works in weston 12
* the same vscode version with same arguments works in gnome ubuntu lunar wayland desktop
* If I start weston with `--xwayland` and code with x11 backend it works `code-insiders --enable-features=UseOzonePlatform --ozone-platform=x11 --verbose`
Vscode prints a limited number of log lines
`
Warning: 'enable-features' is not in the list of known options, but still passed to Electron/Chromium.
Warning: 'ozone-platform' is not in the list of known options, but still passed to Electron/Chromium.
[0602/131006.348889:ERROR:file_io_posix.cc(152)] open /home/ubuntu/.config/Code - Insiders/Crashpad/pending/0e25bf47-6373-40e3-a323-2f3ce3082e6f.lock: File exists (17)
[25486:0602/131006.350094:WARNING:wayland_object.cc(144)] Binding to wl_seat version 5 but version 7 is available.
`https://gitlab.freedesktop.org/wayland/wayland/-/issues/93Contradiction in wl_surface description2023-07-08T09:54:57ZScott AndersonContradiction in wl_surface descriptionFrom the description of `wl_surface`:
>Destroying the role object does not remove the role from the
wl_surface, but it may stop the wl_surface from "playing the role".
For instance, if a wl_subsurface object is destroyed, the wl_surface...From the description of `wl_surface`:
>Destroying the role object does not remove the role from the
wl_surface, but it may stop the wl_surface from "playing the role".
For instance, if a wl_subsurface object is destroyed, the wl_surface
it was created for will be unmapped and forget its position and
z-order. It is allowed to create a wl_subsurface for the same
wl_surface again, but it is not allowed to use the wl_surface as
a cursor (cursor is a different role than sub-surface, and role
switching is not allowed).
However, comparing that to the description of `wl_subsurface.destroy`:
>The sub-surface interface is removed from the wl_surface object
that was turned into a sub-surface with a
wl_subcompositor.get_subsurface request. The wl_surface's association
to the parent is deleted, and the wl_surface loses its role as
a sub-surface. The wl_surface is unmapped immediately.
So wl_surface says the role is kept (specifically giving wl_subsurface as an example), while wl_subsurface says it is not. wl_surface is also describing behaviour of forgetting the parent's position and z-order, which is not described anywhere in the wl_subsurface description.
I would personally side with the behaviour wl_surface describes, as I cannot think of a reason why wl_subsurface would need to override the normal wl_surface role behaviour, and leads to a more consistent implementation for compositors.
It also matches that behaviour that weston and wlroots have actually implemented:
```
[3332352.321] -> wl_compositor@4.create_surface(new id wl_surface@3)
[3332352.333] -> wl_compositor@4.create_surface(new id wl_surface@7)
[3332352.344] -> wl_subcompositor@5.get_subsurface(new id wl_subsurface@8, wl_surface@7, wl_surface@3)
[3332352.371] -> wl_subsurface@8.destroy()
[3332352.377] -> xdg_wm_base@6.get_xdg_surface(new id xdg_surface@9, wl_surface@7)
[3332352.396] -> xdg_surface@9.get_toplevel(new id xdg_toplevel@10)
[3332352.509] wl_display@1.delete_id(8)
[3332352.531] wl_display@1.error(xdg_surface@9, 0, "Cannot assign role xdg_toplevel to wl_surface@7, already has role wl_subsurface
```
I have not tested any other compositors.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/151Members meetings2023-07-06T12:31:45ZSimon Sercontact@emersion.frMembers meetingsThis issue tracks meetings held with wayland-protocols members. Meeting notes are collected here.This issue tracks meetings held with wayland-protocols members. Meeting notes are collected here.https://gitlab.freedesktop.org/wayland/weston/-/issues/770Timeline debug scope crash at start-up / begin fence sync2023-07-05T10:52:26ZMarius VladTimeline debug scope crash at start-up / begin fence syncWe seem to be crashing in `timeline_render_point_handler()` before mapping any window/surface, looks like it was introduced with 7c9c545b4e9a591221548b59b298a4a7d96f6018
Steps to reproduce:
1. Start weston with --debug
2. `$ weston-de...We seem to be crashing in `timeline_render_point_handler()` before mapping any window/surface, looks like it was introduced with 7c9c545b4e9a591221548b59b298a4a7d96f6018
Steps to reproduce:
1. Start weston with --debug
2. `$ weston-debug timeline`
3. Map any window
```
#5 0x00007f6ff1c2adf2 in __GI___assert_fail
(assertion=0x7f6ff0bc40df "result_available == GL_TRUE", file=0x7f6ff0bc40b8 "../libweston/renderer-gl/gl-renderer.c", line=370, function=0x7f6ff0bc51e0 <__PRETTY_FUNCTION__.42> "timeline_render_point_handler") at ./assert/assert.c:101
#6 0x00007f6ff0bb5120 in timeline_render_point_handler (fd=51, mask=1, data=0x55e63f9d04d0) at ../libweston/renderer-gl/gl-renderer.c:370
#7 0x00007f6ff1b59642 in wl_event_loop_dispatch (loop=0x55e63f1c9440, timeout=<optimized out>, timeout@entry=-1) at ../src/event-loop.c:1104
#8 0x00007f6ff1b57285 in wl_display_run (display=0x55e63f1c9350) at ../src/wayland-server.c:1493
#9 0x00007f6ff1dff726 in wet_main (argc=1, argv=0x7fffb93f0428, test_data=0x0) at ../compositor/main.c:4226
#10 0x000055e63e61015e in main (argc=5, argv=0x7fffb93f0428) at ../compositor/executable.c:33
```https://gitlab.freedesktop.org/wayland/weston/-/issues/771What can cause frequent calls to glDrawArrays in Weston?2023-07-05T08:40:21ZEdgar NeubauerWhat can cause frequent calls to glDrawArrays in Weston?I have to debug a scenario in a PowerVR based embedded Linux system where there is high resource consumption and 2D rendering is heavily loaded. Using a call tracer it seems to me that a lot of glDrawArrays calls are set off not in the a...I have to debug a scenario in a PowerVR based embedded Linux system where there is high resource consumption and 2D rendering is heavily loaded. Using a call tracer it seems to me that a lot of glDrawArrays calls are set off not in the apps themselves but in weston, usually with these callstacks:
```
#0 0x0000007f9e03edb0 in glDrawArrays () from /usr/lib/libGLESv2.so.2
#1 0x0000007f9e1cf1fc in ?? () from /usr/lib/libweston-8/gl-renderer.so
#2 0x0000007f9e1cf5d8 in ?? () from /usr/lib/libweston-8/gl-renderer.so
#3 0x0000007f9e1d00fc in ?? () from /usr/lib/libweston-8/gl-renderer.so
#4 0x0000007f9e22b564 in ?? () from /usr/lib/libweston-8/drm-backend.so
#5 0x0000007f9e224f9c in ?? () from /usr/lib/libweston-8/drm-backend.so
#6 0x0000007f9e225120 in ?? () from /usr/lib/libweston-8/drm-backend.so
#7 0x0000007f9ebfbe50 in ?? () from /usr/lib/libweston-8.so.0
#8 0x0000007f9ebabf90 in wl_event_loop_dispatch () from /usr/lib/libwayland-server.so.0
#9 0x0000007f9ebaa798 in wl_display_run () from /usr/lib/libwayland-server.so.0
#10 0x0000007f9edab47c in wet_main () from /usr/lib/weston/libexec_weston.so.0
#11 0x0000007f9ec50d78 in __libc_start_main () from /lib64/libc.so.6
#12 0x00000000004007a0 in ?? ()
#0 0x0000007f9e03edb0 in glDrawArrays () from /usr/lib/libGLESv2.so.2
#1 0x0000007f8fceaa6c in ?? () from /usr/lib/libweston-8/gl-renderer.so
#2 0x0000007f8fd3e3c0 in ?? () from /usr/lib/libweston-8/drm-backend.so
#3 0x0000007f8e836c80 in update_buffer_nativesurface ()
from /usr/lib/weston/libtsd.ivi.shell.ivi_shell.so
#4 0x0000007f8e836a2c in ?? ()
from /usr/lib/weston/libtsd.ivi.shell.ivi_shell.so
#5 0x0000007f903774a4 in ffi_call_SYSV () from /usr/lib/libffi.so.6
#6 0x0000007f90377c80 in ffi_call () from /usr/lib/libffi.so.6
#7 0x0000007f906c80f4 in ?? () from /usr/lib/libwayland-server.so.0
#8 0x0000007f906c56a8 in ?? () from /usr/lib/libwayland-server.so.0
#9 0x0000007f906c7034 in wl_event_loop_dispatch ()
from /usr/lib/libwayland-server.so.0
#10 0x0000007f906c5798 in wl_display_run ()
from /usr/lib/libwayland-server.so.0
#11 0x0000007f908c647c in wet_main () from /usr/lib/weston/libexec_weston.so.0
#12 0x0000007f9076bd78 in __libc_start_main () from /lib64/libc.so.6
#13 0x00000000004007a0 in ?? ()
```
These glDrawArrays calls seem to be caused by messages from some of the OpenGL apps but I don't know which ones. Other apps also use OpenGL but do not cause such callstacks in weston.
My concern is that these glDrawArrays calls compete with the calls from the other apps for gpu and slow those down. Can someone tell me if such behaviour is normal and what exactly makes weston cast these calls?
Regards.https://gitlab.freedesktop.org/wayland/weston/-/issues/13libweston-desktop2023-07-04T15:34:32ZBugzilla Migration Userlibweston-desktop## Submitted by Quentin 'SardemFF7' Glidic `@sardemff7`
Assigned to **Quentin 'SardemFF7' Glidic `@sardemff7`**
**[Link to original bug (#7519)](https://phabricator.freedesktop.org/T7519)**
## Description
An abstraction library fo...## Submitted by Quentin 'SardemFF7' Glidic `@sardemff7`
Assigned to **Quentin 'SardemFF7' Glidic `@sardemff7`**
**[Link to original bug (#7519)](https://phabricator.freedesktop.org/T7519)**
## Description
An abstraction library for compositors willing to support desktop-like shells.Morgane GlidicMorgane Glidichttps://gitlab.freedesktop.org/wayland/weston/-/issues/11Libweston meta-task2023-07-04T15:34:32ZBugzilla Migration UserLibweston meta-task## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#7439)](https://phabricator.freedesktop.org/T7439)**
## Description
When working towards libweston, we notice all kinds of things w...## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#7439)](https://phabricator.freedesktop.org/T7439)**
## Description
When working towards libweston, we notice all kinds of things we should fix, but cannot fix them on the spot. Instead, we file new tasks that will block this task.https://gitlab.freedesktop.org/wayland/weston/-/issues/4Check toytoolkit shm space reservation.2023-07-04T15:34:32ZBugzilla Migration UserCheck toytoolkit shm space reservation.## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#20)](https://phabricator.freedesktop.org/T20)**
## Description
In window.c, display_create_shm_surface() uses data_length_for_shm_...## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#20)](https://phabricator.freedesktop.org/T20)**
## Description
In window.c, display_create_shm_surface() uses data_length_for_shm_surface() to compute the pool size. However, that hardcodes RGBA32 pixel format, even if we were going to use RGB565.
Review the code, and fix the overallocation if it indeed happens.https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/59linux-dmabuf: figure out a good way to broadcast set of supported formats/mod...2023-07-03T08:17:48ZSimon Sercontact@emersion.frlinux-dmabuf: figure out a good way to broadcast set of supported formats/modifiersOn my AMD machine linux-dmabuf advertises 310 format/modifier pairs. That's `310 * (4 + 4 + 8) = 4960` bytes worth of data being transferred each time a client connects (message header + format + modifier).
This is about to get worse wi...On my AMD machine linux-dmabuf advertises 310 format/modifier pairs. That's `310 * (4 + 4 + 8) = 4960` bytes worth of data being transferred each time a client connects (message header + format + modifier).
This is about to get worse with https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/8.
Using a `wl_array` to send one format and multiple modifiers doesn't help too much: each of the 41 formats has ~7.56 modifiers, so the total size is `41 * (4 + 4 + 4 + 8*7.56) = 2972` bytes (message header + format + array size + modifiers).https://gitlab.freedesktop.org/wayland/weston/-/issues/767Doc forgets to tell about systemd-notify.so2023-06-29T19:01:21ZPekka Paalanenppaalanen@gmail.comDoc forgets to tell about systemd-notify.soWe have documentation about how to run Weston from a systemd service. It says nowhere that you also need to load `systemd-notify.so` in Weston, otherwise systemd thinks Weston is stuck starting and kills it.
Reported on IRC: https://oft...We have documentation about how to run Weston from a systemd service. It says nowhere that you also need to load `systemd-notify.so` in Weston, otherwise systemd thinks Weston is stuck starting and kills it.
Reported on IRC: https://oftc.irclog.whitequark.org/wayland/2023-06-29#32268105;https://gitlab.freedesktop.org/wayland/wayland/-/issues/391Unable to set event queue2023-06-28T08:31:55ZKarl FleischmannUnable to set event queueI am unable to set a custom event queue to the main display object via `wl_proxy_set_queue()`.
This seems to stem from:
- `wl_list_remove(&proxy->queue_link)` being called on an uninitialized `queue_link` attribute (see https://gitlab.fr...I am unable to set a custom event queue to the main display object via `wl_proxy_set_queue()`.
This seems to stem from:
- `wl_list_remove(&proxy->queue_link)` being called on an uninitialized `queue_link` attribute (see https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/src/wayland-client.c#L2374),
- which will segfault in `wl_list_remove()` because `elm = {prev=0x0, next=0x0}` essentially (see https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/src/wayland-util.c#L56).
I briefly looked at the source and the commit that introduces this attribute and I cannot find a proper place where to initialize this myself. Internally `wl_list_init(&proxy->queue_link)` seems to only be initialized when `wl_event_queue_release()` or `proxy_destroy()` is called, and these seem to be static functions.
Minimimal reproduction example:
```c
# File: main.c
#include <wayland-client.c>
int
main (void)
{
struct wl_display *display = wl_display_connect(NULL);
struct wl_event_queue *queue = wl_display_create_queue(display);
wl_proxy_set_queue((struct wl_proxy *)display, queue);
return 0;
}
```
Compile with `gcc -lwayland-client main.c`, run with `./a.out`.
In case I am doing something wrong - which is totally possible - let me know where to find a proper explanation of how to create custom event queues.
Thanks! :slight_smile: :v:
Edit:
I have forgotten to mention: I am fairly sure that this worked prior to wayland-1.22. And the commit that introduced the `wl_list_remove()` call was 3 months ago: https://gitlab.freedesktop.org/wayland/wayland/-/commit/674145dc3f621e5a3673714c7527d0e1c5336ab1https://gitlab.freedesktop.org/wayland/weston/-/issues/421Ensure drm_outputs get destroyed on shutdown2023-06-27T11:06:34ZLeandro RibeiroEnsure drm_outputs get destroyed on shutdownThe following discussion from !441 should be addressed:
- [ ] @pq started a [discussion](https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/441#note_588879): (+12 comments)
> Probably should `assert(!crtc->output);` he...The following discussion from !441 should be addressed:
- [ ] @pq started a [discussion](https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/441#note_588879): (+12 comments)
> Probably should `assert(!crtc->output);` here, otherwise the tear-down sequence would be bad and probably doing a use-after-free.
See https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/441#note_595155 for an analysis of what should be fixed.https://gitlab.freedesktop.org/wayland/weston/-/issues/764gl-renderer: Vertex clipping optimizations break rendering of rotated clients2023-06-26T12:19:43ZPhilipp Zabelphilipp.zabel@gmail.comgl-renderer: Vertex clipping optimizations break rendering of rotated clientsCommit a4d31fa8bdc00b04359e42f63e93c134cdf0384f ("gl-renderer: Decouple coord space transformation from clipper") from !1156 breaks border rendering of rotated clients.Commit a4d31fa8bdc00b04359e42f63e93c134cdf0384f ("gl-renderer: Decouple coord space transformation from clipper") from !1156 breaks border rendering of rotated clients.https://gitlab.freedesktop.org/wayland/weston/-/issues/626Screen capturing2023-06-26T11:22:25ZpiegamesScreen capturingHello, is there any good way to do some screen shots or capturing the entire output of Weston programatically? I've seen that there is `weston-screenshooter`, but it feels more like a tech demo to me and also I don't think it can take vi...Hello, is there any good way to do some screen shots or capturing the entire output of Weston programatically? I've seen that there is `weston-screenshooter`, but it feels more like a tech demo to me and also I don't think it can take video recordings.
What is the easiest way to capture the output of Weston? FWIW, I am fine with controlling my own Weston session for this purpose (I plan on running a headless nested session in the end).https://gitlab.freedesktop.org/wayland/wayland/-/issues/379Lowering inactive developers/maintainers to reporters2023-06-20T21:52:36ZSimon Sercontact@emersion.frLowering inactive developers/maintainers to reportersI've been looking at the list of people with push access to the wayland org. Some people have made significant contributions in the past (thanks!), but are no longer active (they haven't reviewed/merged/submitted patches in a long time)....I've been looking at the list of people with push access to the wayland org. Some people have made significant contributions in the past (thanks!), but are no longer active (they haven't reviewed/merged/submitted patches in a long time). Having a lot of people with developer/maintainer access is suboptimal regarding security: the more people have this role, the more likely credentials with write access to all repos under the org can be leaked.
It would be nice to lower the permissions of people who don't need developer/maintainer access to reporter only. The role can be increased again if these people start contributing again.
This is about the wayland org only, if someone is active in one project under the org but not others we should give them permissions on the specific project instead of the whole org.
Here is a list: @bryce, @rdp.effort, @gfxstrand, @krh, @sardemff7
Please, speak up in the next month if you want to retain your developer/maintainer access!2023-06-10