@waddlesplash suddenly applied https://review.haiku-os.org/c/haiku/+/4506 without any public discussion. That broke app_server model that supposed to be running only one instance and manage active user sessions. This is actually already working, you can have multiple interactive sessions with remote desktop connection. For local desktop only screen and input switching is missing to be working. Now it is broken.
WHY???
Waddlesplash, please do not push your per-user app_server model in such dirty way.
There were collected comments from a number of people (including you.) Two other developers besides myself were OK with merging it “at least for now,” understanding that it may get revisited when (if?) we add proper multiuser support at a later date. (One of those developers was also tentatively in favor of the ideas to make app_server a single-user application, anyway.) How in the world is that “no public discussion”?
Haiku’s GUI is single-user-only at present (or at least, if it works with multiple users, that is far more by accident than really by design; I understand there’s code for multiple users in app_server, but it cannot be called anything like “complete” in the slightest for a myriad of reasons.)
Because that patch will fix the most-upvoted ticket on the bugtracker at present (#12534) while having comparatively few side effects. I didn’t even know RemoteDesktop still worked at all; I was under the impression that the HTML5 RemoteDesktop merge broke it (i.e. you have to use the HTML5 one, not the native one, at present), and it was kind of a pain to set that up, anyway.
Multiple users at the GUI level is not something we really support right now, anyway. So long as RemoteDesktop still works for a single user, that’s the thing we care about not regressing.
A further thought: I don’t know how this could, at present, actually break any of the things you are discussing here. There is only one “user” (root) by default, and app_server of course still runs as it. If the problem is somehow related to environment variables, well, then we are right back to where we started anyway.
Whatever else comes of this discussion, though, I will say this: I am not a particular fan of how you (@X512) come make posts on the forums whenever a technical discussion goes some way you do not like. The last time there was a dispute like this between you and I, it at least involved code you had written or were actively working on, so it made some sense to do.
This time, however, it does not involve code you have written or worked on, or (as far as I know) have plans to work on. Presuming I understand things correctly, it will not even break the case you claim it breaks here (and if it really did, that might merit a ticket, and we can look into it from there. “Complaining on the forums” is not a usual method of reporting bugs.)
What, exactly, do you expect to accomplish by making these forum posts? Getting the community to support your point of view? But these are technical considerations; so long as everything works (and works well), why do the non-technical people in the community care what precise decisions are made?
Haiku developers should not be so aggressiv in the public. It is not the first time a release break something working good before. Use the Bug tracker to report is the right way.
Also, why are you getting so angry? This didn’t even make it to a beta release, let alone a RC or a RTM product, you could’ve just emailed him or IMed him about this and been generally calm about it, making a forum thread makes it seem like you’re looking for hostile attention towards @waddlesplash.
I am not ok with merging this, otherwise I would have given a +2 and merged it. Please do not put words in my mouth.
I commented that it could be OK if there was no better solution, then Axel proposed a better solution.
Yes, I tend to agree with this. The tone of these discussions is not really appropriate. And it is annoying everyone. If you are not happy you can for example push a revert commit to Gerrit and see if someone will merge it, or propose a better implementation (which I was planning to do today, but apparently I will be dealing with forum drama and not want to work on Haiku with a bunch of immature people acting like children instead of having a civilized discussion. again.)
The publicity of the actions relating to the issue
I can see how (1) is not ideal, but without (1) you would not get (2). I, for one, would not have known about (2) without (1)… You can see why (1) happens now?
I don’t have a horse in this race, but I certainly don’t like the way we keep getting these confrontations and believe that some better scheme needs to be found to resolve the issues. This seems a lot like what happened recently in the .Net world with the .Net Foundations and Microsoft doing a lot of heavy handed things that upset a lot of people. So, it’s not just Haiku, it’s not just specific individuals, it is a break down in communication and an ignoring of protocols on all sides.
It will be better to open separate forum for development discussion, mailing lists have bad user experience for many people. For example 3deyes said that mailing lists are hard to use.
I agree,I often follow the development-related topics here because I find it interesting but I never use mailing lists as I have enough spam in my mailbox already.
However,I’m not sure if it’s really worth hosting another forum just for development.
Can’t we just make some category that is hidden by default,where everyone who wants can subscribe to?
I agree that these kinds of discussions should be held at the development mailing list. No need to make drama at the public forums, it is not cool at all.
No, this isn’t excising the rot. It creates the rot by metaphorically pulling a fruit (commit) out of the fridge (developer channels) where it could’ve ripened at the right pace and putting it in direct sunlight (this forum) where it becomes overripe and begins to rot and stink up the place.
There are dedicated developer channels for this, the forum not being one of them.
Just going to mute this topic from here on out, wew.
