Folks,
The Gitlab experiment seems to be going well. For the last release, more than half the patches were submitted as Gitlab merge requests, so that seems to be working well for us.
There are still improvements we can make, and of course many more Gitlab features that we could start using, but before investing more effort we need to decide whether we want to use it going forward.
So now that you have had a chance to try it, what do you people think? Should we adopt Gitlab as our development platform?
Am 24.05.2022 um 12:12 schrieb Alexandre Julliard julliard@winehq.org:
So now that you have had a chance to try it, what do you people think? Should we adopt Gitlab as our development platform?
I'll add a very helpful non-response here: I am happy either way :-)
I find submitting merge requests a little bit more work than my old git-send-email setup, but I am still working my way into it and haven't tried the gitlab command line tools yet.
If gitlab frees up your (Alexandre's) time by not having to maintain the homebrew patch tracker I think that's enough for it to be a win.
On 5/24/22 11:12, Alexandre Julliard wrote:
Folks,
The Gitlab experiment seems to be going well. For the last release, more than half the patches were submitted as Gitlab merge requests, so that seems to be working well for us.
There are still improvements we can make, and of course many more Gitlab features that we could start using, but before investing more effort we need to decide whether we want to use it going forward.
So now that you have had a chance to try it, what do you people think? Should we adopt Gitlab as our development platform?
Hi,
I think it still has some rough edges but I really appreciate the cooperative aspect to it, where we can more freely and openly assign patches for review. Even if I'm going to list negative points below for reference I'm happy with it.
More precisely, the rough edges are a bit related to the current patch submission process, and I think they could be smoothed out if Gitlab was the preferred development platform:
* The sign-off requirement makes it a bit more painful to create MR than it could be. There's git rebase --sign-off, but it's a bit inconvenient to script. As other have mentioned already, reviewer information is also not included in commits anymore, which feels like a loss.
* Mixing patch reviews from the M-L with Gitlab is also a bit awkward, comments are not really well integrated, quoting on Gitlab in a M-L friendly way is inconvenient, and M-L comments are also not formatted in a very readable way.
* In the same way, approving patches with Sign-off on the M-L doesn't map well to Gitlab, it only creates dangling comments on the MR and are probably not considered as a valid approval. This also means that MR cannot be partially approved (though they can be updated after discussion to only include the good changes).
* We still miss proper testbot integration, though I understand it's in progress. I think it would be nice to have it use commit status API [1] to mark individual commit build / test statuses in MR.
[1] https://docs.gitlab.com/ee/api/commits.html#commit-status
Cheers,
Rémi Bernon rbernon@codeweavers.com writes:
More precisely, the rough edges are a bit related to the current patch submission process, and I think they could be smoothed out if Gitlab was the preferred development platform:
- The sign-off requirement makes it a bit more painful to create MR than it could be. There's git rebase --sign-off, but it's a bit
inconvenient to script. As other have mentioned already, reviewer information is also not included in commits anymore, which feels like a loss.
The current idea is to use git notes to propagate that information from Gitlab, to avoid having to rewrite MR commits. There's an experimental refs/notes/commits branch on the main gitlab tree that you can pull if you'd like to see what it looks like. If this works out we could potentially use it for the original author signoff as well.
On 5/25/22 20:56, Alexandre Julliard wrote:
Rémi Bernon rbernon@codeweavers.com writes:
More precisely, the rough edges are a bit related to the current patch submission process, and I think they could be smoothed out if Gitlab was the preferred development platform:
- The sign-off requirement makes it a bit more painful to create MR than it could be. There's git rebase --sign-off, but it's a bit inconvenient to script. As other have mentioned already, reviewer
information is also not included in commits anymore, which feels like a loss.
The current idea is to use git notes to propagate that information from Gitlab, to avoid having to rewrite MR commits. There's an experimental refs/notes/commits branch on the main gitlab tree that you can pull if you'd like to see what it looks like. If this works out we could potentially use it for the original author signoff as well.
That's neat, I didn't know it was there already!
FWIW it can be configured to be fetched automatically into the local notes with:
git config --add remote.origin.fetch "refs/notes/*:refs/notes/*"
Then `git log` will automatically show notes for each commit that went through Gitlab.
Though beware that if you're already using `git notes` locally, this will cause some conflicts and you need to decide which notes branch to use.
And if you don't use git notes locally, you can safely a '+' in front of the fetch refspec to make sure git fetch will force update it from origin.
Cheers,
Rémi Bernon rbernon@codeweavers.com writes:
Though beware that if you're already using `git notes` locally, this will cause some conflicts and you need to decide which notes branch to use.
And if you don't use git notes locally, you can safely a '+' in front of the fetch refspec to make sure git fetch will force update it from origin.
If you want to also use notes locally, you should be able to do something like:
git config remote.origin.fetch "+refs/notes/commits:refs/notes/gitlab" git config notes.displayRef "refs/notes/gitlab"
I'm pretty happy with it.
Things that could be improved are:
-Testbot integration as CI pipeline. -Maybe another pipeline, that checks for validity of MRs like, if all signoffs are set and if the submitter used the correct commit message syntax.
Thanks, Bernhard
Am Di., 24. Mai 2022 um 11:12 Uhr schrieb Alexandre Julliard julliard@winehq.org:
Folks,
The Gitlab experiment seems to be going well. For the last release, more than half the patches were submitted as Gitlab merge requests, so that seems to be working well for us.
There are still improvements we can make, and of course many more Gitlab features that we could start using, but before investing more effort we need to decide whether we want to use it going forward.
So now that you have had a chance to try it, what do you people think? Should we adopt Gitlab as our development platform?
-- Alexandre Julliard julliard@winehq.org
On 5/24/22 04:12, Alexandre Julliard wrote:
Folks,
The Gitlab experiment seems to be going well. For the last release, more than half the patches were submitted as Gitlab merge requests, so that seems to be working well for us.
There are still improvements we can make, and of course many more Gitlab features that we could start using, but before investing more effort we need to decide whether we want to use it going forward.
So now that you have had a chance to try it, what do you people think? Should we adopt Gitlab as our development platform?
I don't think Gitlab is acceptable as a review platform as long as it doesn't have real support for threading (that is, nesting comments more than one level deep). That's not a failure of the mailing list bridge so much as it is a failure of the platform.
The requirement to sign off on a whole pull request (rather than individual patches) is unfortunate, but I can understand finding that a worthwhile sacrifice to make.
The inability to add comments to a patch which will not be committed is also unfortunate. Perhaps we can come up with a new convention for those, and automatically strip those out? Those who have experience with pull requests—do any other projects have a way of dealing with this?
Creating new pull requests is less convenient than it could be, although I can probably live with that.
Most of the benefits to Gitlab are applicable to new users and to the project maintainer, so there's not much on the "pro" side for me. One potential benefit I have noted is that it does seem potentially helpful to have a list of pull requests assigned to me, in case any of the relevant emails get lost. No other benefits have appeared to me at the moment, though.
Overall the benefits to gitlab don't seem to outweigh the drawbacks, at least not in its current state.
On 5/25/22 14:39, Zebediah Figura wrote:
Most of the benefits to Gitlab are applicable to new users and to the project maintainer, so there's not much on the "pro" side for me. One potential benefit I have noted is that it does seem potentially helpful to have a list of pull requests assigned to me, in case any of the relevant emails get lost. No other benefits have appeared to me at the moment, though.
Actually, now that I've discovered the syntax (thanks Rémi), I find the following a more convenient way to retrieve larger patch series:
git fetch <remote> merge-requests/123/head
followed by references to FETCH_HEAD. So that's another benefit.
I didn't feel much benefits in the process of submitting patches through gitlab compared to sending them to the ML, nor any complications on that way. The thing which I probably find more convenient is accessing sent but not committed patches (sent by others): it could be I was missing some obvious way in the ML workflow but in general fetching a patch from gitlab to apply locally (using git) feels easier to me, especially if that involves some rebasing.
On Tue, May 24, 2022 at 11:12:32AM +0200, Alexandre Julliard wrote:
So now that you have had a chance to try it, what do you people think? Should we adopt Gitlab as our development platform?
Now that we have the reviewers' approvals stored in git's notes, I'm generally happy with it.
Sending in patches is pretty much break-even.
I do find reviewing on gitlab easier: one doesn't have to manually collect the individual emails into one's local tree - simply fetching the branch is much nicer. This is especially useful when v(n+1) comes in - it's very easy to see diff betweeen it and vn.
I can see cases where signing off individual patches, rather the entire MR, might be beneficial, but I'm not too bothered about losing that (and perhaps it will encourage better separated MRs). Having multiple reviewers helps mitigate this too.
The MR tracker is much nicer than our current patch tracker - it's very easy to see which MRs are pending your review.
So, I'm happy to switch.
Huw.
On 5/24/22 11:12, Alexandre Julliard wrote:
Folks,
The Gitlab experiment seems to be going well. For the last release, more than half the patches were submitted as Gitlab merge requests, so that seems to be working well for us.
There are still improvements we can make, and of course many more Gitlab features that we could start using, but before investing more effort we need to decide whether we want to use it going forward.
So now that you have had a chance to try it, what do you people think? Should we adopt Gitlab as our development platform?
What I like about Gitlab:
* push/fetch model eliminates ML hacks by design (where we give up proper git history when sending an email, only to have hackish reconstruction of it in patch tracker, TestBot and reviewers' tools).
* It provides a platform where having Wine Gecko repo fits Wine infrastructure.
* It gives us a nice place to share WIP branches within Wine infrastructure.
* It seems to have a good potential for automation.
On top of above it makes Alexandre's life easier, so I think it's good enough to continue adopting it. There are some things that could be improved:
* The ability of reviewer to push simple fixups to MRs. Gitlab provides some support for it, but it currently doesn't fit our workflow. For the existing option to work, reviewer would need commit access to the target branch. I worked around that with Huw by giving him access to my tree instead, but that does not scale.
* Related to above, when reviewer pushes to MR, MR creator is used by ML bridge as a sender. It seems like it should use the reviewer instead and Gitlab has that information. Eg. [1] should use Huw as a sender.
* I think that a mailing list dominated by a bot does not give an impression welcoming for general discussion. If we're moving forward with this, I think we should move Gitlab bridge to a separated mailing list. We had wine-patches in the past (although in this case it would contain review comments as well).
Jacek
[1] https://www.winehq.org/pipermail/wine-devel/2022-May/217574.html
On 5/27/22 07:34, Jacek Caban wrote:
- I think that a mailing list dominated by a bot does not give an
impression welcoming for general discussion. If we're moving forward with this, I think we should move Gitlab bridge to a separated mailing list. We had wine-patches in the past (although in this case it would contain review comments as well).
If our intent is to switch to gitlab because mailing lists are too difficult for people to work with, then it seems we shouldn't have any discussion at all take place on a mailing list, otherwise it'll be missed by the people who are only using gitlab. Not that I know of a better way to have such discussion...
On 5/27/22 17:30, Zebediah Figura (she/her) wrote:
On 5/27/22 07:34, Jacek Caban wrote:
- I think that a mailing list dominated by a bot does not give an
impression welcoming for general discussion. If we're moving forward with this, I think we should move Gitlab bridge to a separated mailing list. We had wine-patches in the past (although in this case it would contain review comments as well).
If our intent is to switch to gitlab because mailing lists are too difficult for people to work with, then it seems we shouldn't have any discussion at all take place on a mailing list, otherwise it'll be missed by the people who are only using gitlab. Not that I know of a better way to have such discussion...
Imho the mailing list still makes sense, for general Wine development discussion, though the volume may be much smaller than what we currently have.
Maybe we don't currently have many discussion either because the mailing list is felt more as a place for patches, and that discussions are believed to happen elsewhere, or because discussions go more often unnoticed under the volume of patches.
Then I personally also don't think that the mailing list bridge is doing a great job, and if we decide to use Gitlab as the primary platform I'd also vote for using a different mailing list for the bridge, for people willing to stick to it. (*)
(*) Actually, if we decide to adopt Gitlab as the primary development platform, I think it'd be better if reviews were done on Gitlab entirely, if we cannot find a way to better format mail replies, they are hardly readable at the moment. Even replying to Gitlab builtin mail notifications does a better job.
Cheers,
On 5/27/22 10:46, Rémi Bernon wrote:
On 5/27/22 17:30, Zebediah Figura (she/her) wrote:
On 5/27/22 07:34, Jacek Caban wrote:
- I think that a mailing list dominated by a bot does not give an
impression welcoming for general discussion. If we're moving forward with this, I think we should move Gitlab bridge to a separated mailing list. We had wine-patches in the past (although in this case it would contain review comments as well).
If our intent is to switch to gitlab because mailing lists are too difficult for people to work with, then it seems we shouldn't have any discussion at all take place on a mailing list, otherwise it'll be missed by the people who are only using gitlab. Not that I know of a better way to have such discussion...
Imho the mailing list still makes sense, for general Wine development discussion, though the volume may be much smaller than what we currently have.
Maybe we don't currently have many discussion either because the mailing list is felt more as a place for patches, and that discussions are believed to happen elsewhere, or because discussions go more often unnoticed under the volume of patches.
I've seen this kind of thought floated several times, and I'm not sure I understand the reasoning. What kind of discussions or replies are you expecting to see that don't currently happen?
Then I personally also don't think that the mailing list bridge is doing a great job, and if we decide to use Gitlab as the primary platform I'd also vote for using a different mailing list for the bridge, for people willing to stick to it. (*)
(*) Actually, if we decide to adopt Gitlab as the primary development platform, I think it'd be better if reviews were done on Gitlab entirely, if we cannot find a way to better format mail replies, they are hardly readable at the moment. Even replying to Gitlab builtin mail notifications does a better job.
I'd really like to stress my opposition to this. Gitlab's UI is horrible, and so are the default mail notifications. I don't intend to use either to review.
On 27/05/2022 21:03, Zebediah Figura wrote:
On 5/27/22 10:46, Rémi Bernon wrote:
On 5/27/22 17:30, Zebediah Figura (she/her) wrote:
On 5/27/22 07:34, Jacek Caban wrote:
- I think that a mailing list dominated by a bot does not give an
impression welcoming for general discussion. If we're moving forward with this, I think we should move Gitlab bridge to a separated mailing list. We had wine-patches in the past (although in this case it would contain review comments as well).
If our intent is to switch to gitlab because mailing lists are too difficult for people to work with, then it seems we shouldn't have any discussion at all take place on a mailing list, otherwise it'll be missed by the people who are only using gitlab. Not that I know of a better way to have such discussion...
Imho the mailing list still makes sense, for general Wine development discussion, though the volume may be much smaller than what we currently have.
Maybe we don't currently have many discussion either because the mailing list is felt more as a place for patches, and that discussions are believed to happen elsewhere, or because discussions go more often unnoticed under the volume of patches.
I've seen this kind of thought floated several times, and I'm not sure I understand the reasoning. What kind of discussions or replies are you expecting to see that don't currently happen?
Then I personally also don't think that the mailing list bridge is doing a great job, and if we decide to use Gitlab as the primary platform I'd also vote for using a different mailing list for the bridge, for people willing to stick to it. (*)
(*) Actually, if we decide to adopt Gitlab as the primary development platform, I think it'd be better if reviews were done on Gitlab entirely, if we cannot find a way to better format mail replies, they are hardly readable at the moment. Even replying to Gitlab builtin mail notifications does a better job.
I'd really like to stress my opposition to this. Gitlab's UI is horrible, and so are the default mail notifications. I don't intend to use either to review.
Same. I also like skimming through patches in the mailing list daily (at least titles, components, if it's something I have a vague clue of or simply curiosity). I don't see how that would work on gitlab efficiently without the bridge. I would really not want to have to open up each MR and then do bunch more clicks just to see the commits/patches, I like how it's now, everything in one "list" and one click-one patch. Simple.
I also really dislike how javascript heavy it is (even more than github) and honestly using email client is way simpler for me than web browser. Probably it's for most people, that's why notifications exist and are still in email... I bet I'd miss a lot of things I'm not "subscribed to" without the bridge, when I tried gitlab settings I got overwhelmed by notifications settings so I just sticked to defaults. I don't know if that's enough to keep my current workflow.
On another note, I prefer sending patches too (rather than MRs), but I'm not going to fight over that one. But I'd really like the non-patch-sending email workflow to stay at the very least, if possible.
I haven't commented on the move to GitLab so far because both Alexandre and Jeremy were already well aware of my views long before this move was announced; I wouldn't expect my comments here to change the end result one way or another. Just for the (public) record though, I'd like to explicitly state my support for both Zeb and Gabriel; I think moving to GitLab is the wrong call.
On 27-05-2022 20:11, Gabriel Ivăncescu wrote:
Same. I also like skimming through patches in the mailing list daily (at least titles, components, if it's something I have a vague clue of or simply curiosity). I don't see how that would work on gitlab efficiently without the bridge. I would really not want to have to open up each MR and then do bunch more clicks just to see the commits/patches, I like how it's now, everything in one "list" and one click-one patch. Simple.
I also really dislike how javascript heavy it is (even more than github) and honestly using email client is way simpler for me than web browser. Probably it's for most people, that's why notifications exist and are still in email... I bet I'd miss a lot of things I'm not "subscribed to" without the bridge, when I tried gitlab settings I got overwhelmed by notifications settings so I just sticked to defaults. I don't know if that's enough to keep my current workflow.
On another note, I prefer sending patches too (rather than MRs), but I'm not going to fight over that one. But I'd really like the non-patch-sending email workflow to stay at the very least, if possible.
I agree with all of the points Jacek made, but also very much with the points Gabriel makes here. I used to go through the patches in the mailing list every day, but lately it has become more tedious because I feel like mails about patches are sent to the mailing list twice as often (the [0/1] mails, approvals, reviewer fixups, Alexandre's fixups). Maybe that's just my imagination, but at least plain sign-offs felt much easier to skip through, and also the lack of differences between v1 and v2 at the top of the patches makes it harder to figure out what changed between versions, unless you use the command line to compare merge request versions (I think?).
So if we stick with Gitlab, I think I will just go through the commit log at the end of the day instead, since that's what I already did for Alexandre's patches.
Anyhow, for me, as someone who is not a reviewer, I still think the pros mentioned by Jacek outweigh the cons.
On Fri, May 27, 2022 at 12:03 PM Zebediah Figura zfigura@codeweavers.com wrote:
On 5/27/22 10:46, Rémi Bernon wrote:
On 5/27/22 17:30, Zebediah Figura (she/her) wrote:
On 5/27/22 07:34, Jacek Caban wrote:
- I think that a mailing list dominated by a bot does not give an
impression welcoming for general discussion. If we're moving forward with this, I think we should move Gitlab bridge to a separated mailing list. We had wine-patches in the past (although in this case it would contain review comments as well).
If our intent is to switch to gitlab because mailing lists are too difficult for people to work with, then it seems we shouldn't have any discussion at all take place on a mailing list, otherwise it'll be missed by the people who are only using gitlab. Not that I know of a better way to have such discussion...
Imho the mailing list still makes sense, for general Wine development discussion, though the volume may be much smaller than what we currently have.
Maybe we don't currently have many discussion either because the mailing list is felt more as a place for patches, and that discussions are believed to happen elsewhere, or because discussions go more often unnoticed under the volume of patches.
I've seen this kind of thought floated several times, and I'm not sure I understand the reasoning. What kind of discussions or replies are you expecting to see that don't currently happen?
This thread itself is an example: I didn't see it until today. GitLab allows me to subscribe to the patch discussions that I care about rather than getting the deafening torrent of every single message. So, for me, resurrecting the wine-patches list as the GitLab bridge while leaving process and architecture discussion on wine-devel would be a welcome change. Mailing lists also aren't very friendly when a newcomer wants to reply to a message that was sent before they were subscribed to the list, but GitLab allows newcomers to jump right in.
-Alex
On 03/06/2022 02:50, Alex Henrie wrote:
On Fri, May 27, 2022 at 12:03 PM Zebediah Figura zfigura@codeweavers.com wrote:
On 5/27/22 10:46, Rémi Bernon wrote:
On 5/27/22 17:30, Zebediah Figura (she/her) wrote:
On 5/27/22 07:34, Jacek Caban wrote:
- I think that a mailing list dominated by a bot does not give an
impression welcoming for general discussion. If we're moving forward with this, I think we should move Gitlab bridge to a separated mailing list. We had wine-patches in the past (although in this case it would contain review comments as well).
If our intent is to switch to gitlab because mailing lists are too difficult for people to work with, then it seems we shouldn't have any discussion at all take place on a mailing list, otherwise it'll be missed by the people who are only using gitlab. Not that I know of a better way to have such discussion...
Imho the mailing list still makes sense, for general Wine development discussion, though the volume may be much smaller than what we currently have.
Maybe we don't currently have many discussion either because the mailing list is felt more as a place for patches, and that discussions are believed to happen elsewhere, or because discussions go more often unnoticed under the volume of patches.
I've seen this kind of thought floated several times, and I'm not sure I understand the reasoning. What kind of discussions or replies are you expecting to see that don't currently happen?
This thread itself is an example: I didn't see it until today. GitLab allows me to subscribe to the patch discussions that I care about rather than getting the deafening torrent of every single message. So, for me, resurrecting the wine-patches list as the GitLab bridge while leaving process and architecture discussion on wine-devel would be a welcome change. Mailing lists also aren't very friendly when a newcomer wants to reply to a message that was sent before they were subscribed to the list, but GitLab allows newcomers to jump right in.
-Alex
FWIW, I see you use gmail, so you can just use a filter to send all the mails coming to this list that have [PATCH] in Subject line to a different tag. Which is the same as having two different mailing lists and sending them to different tags (or even remove the mails with [PATCH] which is akin to not subscribing to wine-patches).
On Fri, Jun 3, 2022 at 8:28 AM Gabriel Ivăncescu gabrielopcode@gmail.com wrote:
On 03/06/2022 02:50, Alex Henrie wrote:
On Fri, May 27, 2022 at 12:03 PM Zebediah Figura zfigura@codeweavers.com wrote:
On 5/27/22 10:46, Rémi Bernon wrote:
On 5/27/22 17:30, Zebediah Figura (she/her) wrote:
On 5/27/22 07:34, Jacek Caban wrote:
- I think that a mailing list dominated by a bot does not give an
impression welcoming for general discussion. If we're moving forward with this, I think we should move Gitlab bridge to a separated mailing list. We had wine-patches in the past (although in this case it would contain review comments as well).
If our intent is to switch to gitlab because mailing lists are too difficult for people to work with, then it seems we shouldn't have any discussion at all take place on a mailing list, otherwise it'll be missed by the people who are only using gitlab. Not that I know of a better way to have such discussion...
Imho the mailing list still makes sense, for general Wine development discussion, though the volume may be much smaller than what we currently have.
Maybe we don't currently have many discussion either because the mailing list is felt more as a place for patches, and that discussions are believed to happen elsewhere, or because discussions go more often unnoticed under the volume of patches.
I've seen this kind of thought floated several times, and I'm not sure I understand the reasoning. What kind of discussions or replies are you expecting to see that don't currently happen?
This thread itself is an example: I didn't see it until today. GitLab allows me to subscribe to the patch discussions that I care about rather than getting the deafening torrent of every single message. So, for me, resurrecting the wine-patches list as the GitLab bridge while leaving process and architecture discussion on wine-devel would be a welcome change. Mailing lists also aren't very friendly when a newcomer wants to reply to a message that was sent before they were subscribed to the list, but GitLab allows newcomers to jump right in.
-Alex
FWIW, I see you use gmail, so you can just use a filter to send all the mails coming to this list that have [PATCH] in Subject line to a different tag. Which is the same as having two different mailing lists and sending them to different tags (or even remove the mails with [PATCH] which is akin to not subscribing to wine-patches).
Thanks for the tip. I have altered my filter for wine-devel to separate mail that includes "patch" in the subject line from mail that does not. However, it's still not ideal because Gmail ignores brackets in the search keyword, and there's no way to make the search case-sensitive either. Perhaps those are good reasons to switch to a different email client or provider, but even so, I don't want to have to write a new filter every time I want to subscribe to a particular patch thread.
-Alex
Just noticed this: When you resolve a thread, GitLab will automatically collapse it, but this does not apply to messages from the ML bridge. E.g: https://gitlab.winehq.org/wine/wine/-/merge_requests/217#note_1902
Would be a nice to have feature / fix.
-- Bernhard
Am Di., 24. Mai 2022 um 11:12 Uhr schrieb Alexandre Julliard julliard@winehq.org:
Folks,
The Gitlab experiment seems to be going well. For the last release, more than half the patches were submitted as Gitlab merge requests, so that seems to be working well for us.
There are still improvements we can make, and of course many more Gitlab features that we could start using, but before investing more effort we need to decide whether we want to use it going forward.
So now that you have had a chance to try it, what do you people think? Should we adopt Gitlab as our development platform?
-- Alexandre Julliard julliard@winehq.org
-
Alex Henrie -
Alexandre Julliard -
Bernhard Kölbl -
Gabriel Ivăncescu -
Henri Verbeet -
Huw Davies -
Jacek Caban -
Paul Gofman -
Rémi Bernon -
Stefan Dösinger -
Sven Baars -
Zebediah Figura -
Zebediah Figura (she/her)