See announcment
Other changes:
- Refactor based on -devel port (no autotools)
- Assume maintainership (critical for a lot of my ports)
NOTE: -devel still has more bugfixes, see https://gitlab.freedesktop.org/xorg/xserver/-/compare/xwayland-21.1...master
Details
Details
Diff Detail
Diff Detail
- Repository
- rP FreeBSD ports repository
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 37170 Build 34059: arc lint + arc unit
Event Timeline
Comment Actions
We need to wait for the release rather than using the RC, but it's good to have something ready.
| x11-servers/xwayland/Makefile | ||
|---|---|---|
| 12 | Why using github while the upstream is freedesktop's gitlab ? | |
| 14–15 | Nope, this needs to be x11@ | |
| 36 | Why the switch to github ? | |
Comment Actions
Doesn't matter much because (a) the release is scheduled before 2021Q2 is branched and (b) plasma5-kwin Wayland session is known to be broken on FreeBSD.
| x11-servers/xwayland/Makefile | ||
|---|---|---|
| 12 | Some of the patches are rebased but I'd prefer to avoid hardcoding username. | |
| 14–15 | I don't trust the entirety of x11@: too many ghosts on the roster, review quality is poor, reaction time is slow, obscure QA camouflaging holes in runtime testing, lack of Wayland dogfooding. If someone submits a change then x11@ approves there's no guarantee it won't introduce regressions. Also includes changes indirectly affecting the port in question. | |
| x11-servers/xwayland/Makefile | ||
|---|---|---|
| 36 |
Inherited from rP540545: GitLab as upstream is more annoying than GitHub. See also bug 242329
Doesn't matter with USES=meson, complicates -devel slave port (maybe removed in future) and requires expanding GH_* (or GL_*) variables in PATCH_SITES + PATCHFILES. | |
| x11-servers/xwayland/Makefile | ||
|---|---|---|
| 12 | Patches maybe original (from MR), rebased by sway-hidpi-git maintainer or rebased by me (transient forks on GitHub). On GitLab a commit from a fork can only be referenced from the main repo if it's part of a merge request but on GitHub from any fork. IIRC, the fist patch is rebased by me to drop autotools part (specific to xwayland-21.1 branch) while the rest are by sway-hidpi-git maintainer. | |
| x11-servers/xwayland/Makefile | ||
|---|---|---|
| 14–15 | To clarify: I may trust you but not the rest of x11@. In other distros it's solved by having co-maintainers but bsd.port.mk only supports 1 address. A possible solution is to create a new team dedicated to Wayland. If this port stays under x11@ I'm not interested anymore, so wlroots package will keep using xwayland-devel to ensure best QA. | |
| x11-servers/xwayland/Makefile | ||
|---|---|---|
| 14–15 | If we have a problem of trust here we need to work on it. What would be the problem with that port belonging to x11@ ? what will the fact that you are the official maintainer of the port would solve vs x11@ being the maintainer ? x11@ is a team this is the way we do co-mentoring, you can be part of that team if needed. | |
| x11-servers/xwayland/Makefile | ||
|---|---|---|
| 14–15 | It's been offered many times in the past even. Lack of trust in x11@ isn't the project's problem, it's yours. Trying to work around everybody's personal problem is what lead to x11 being, in the past, so dysfunctional. Now that it's more functional, let's not undermine it with the assumption it doesn't work. To clarify: I agree with bapt@ and manu@ on this. | |
| x11-servers/xwayland/Makefile | ||
|---|---|---|
| 14–15 | (This reply was drafted 1 year ago but not submitted to restore ceasefire until D35662 relitigated)
x11@ has very large scope. Not all of those are well maintained. It's hard to identify people responsible for a subset of ports while maintainer timeout was revoked. In x11-servers/xwayland case one needs to use Wayland but also avoid sinking into Wayland-only fundamentalism.
Better QA, timely updates, backporting fixes and consumers insight. For review no rubberstamps, no immunity to timeouts, implicit approvals after frequent changes. Actually, I don't request maintainership often. For me, maintainership is very time consuming because it requires exhaustive understanding of every little detail the port (rather than vendor code) does and cooperation with upstream. Easier for ports I've created myself than adopted. Elsewhere (e.g., ffmpeg, x264, icu, alacritty) I get by with implicit approvals while limiting to updates (trying hard to avoid bandwagoning unrelated changes unlike some other ports/ committers).
What's on the mentoring menu? Meetings/chats are non-starter due to privacy and respect for outside contributors.
I want clear responsibilites, not maintaining all/unknown x11@ ports. Dilluting that by waving a team banner is the opposite, ripe for abuse. After being part of gecko@ I've learnt volunteer teams rarely work. As volunteers work at different pace the cooperation itself becomes toxic, killing either the initiator by overwork or the recipient(s) due to pressure/guilt.
Team dynamics are not the same as co-maintainership. Look at /usr/src/MAINTAINERS file or how FreeBSD Project grants commit bits. Contributors are trusted as individuals, not based on their affiliation.
Sure. I didn't imply otherwise. Or did you miss I'm the current maintainer of xwayland-devel, the port this work is based on?
Disagree. x11@ doesn't exist in vacuum, it's influenced by other teams, contributors' and users' expectations. | |