Time for the annual 0.20 release? #1471
Comments
|
At the very least we'd need to merge this first: #1460 And I've been trying to stress test it but I'd appreciate it if the rest of you also did a round as well, as a lot of components have changed since the last stable release. |
|
Now that #1460 appears to be merged, is there anything else holding back the next release, besides stress testing? |
|
I've noticed a regression on Solus Linux between 0.19.0 and git master where if PAM fails (such as the user entering an incorrect password) then the user is left at blank screen without any feedback on what went wrong or any ability to go back to the login screen (the user must switch to a TTY in order to restart SDDM). Has anyone else noticed this? |
Please next time create a separate issue, it makes it easier to track these things. Thanks a lot for the research though, it made the fixing much easier. |
|
Any chance for a new version in time for Plasma 5.24? |
|
Seems that's a nope... Hopefully 5.25! |
|
When is the rootless Xorg and Wayland release? |
5.25.1 is here. I want to say something sarcastic. You're guys doing the great job. |
|
Seems that's a nope... Hopefully 5.26! |
|
Seems that's a nope... Hopefully 5.27! lol |
|
Year of the SDDM release? |
|
Century of the SDDM release :)
пт, 14 окт. 2022 г., 16:45 Samisafool ***@***.***>:
… Year of the SDDM release?
—
Reply to this email directly, view it on GitHub
<#1471 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE6HJINZXKB6CM5Z76CUXVTWDFBUJANCNFSM5H6U6FXA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
GDM is a great alternative |
|
Dublicates: #1579 #1549 @aleixpol @plfiorini @davidedmundson can you give any timeline or name the showstopper petty please Edit: Would it help you if I write a Github Action that can automate the release and upload of artifacts? |
|
I think we are ready for a release, @plfiorini what do you think? |
Would appreciate it as it should introduce running SDDM on Wayland (#1393), right? :) |
|
It'd be great to include this PR in the release: #1622 |
|
Any updates? Fedora is planning to switch the greeter to wayland by default on Fedora 38 with next February as the deadline. https://fedoraproject.org/wiki/Changes/WaylandByDefaultForSDDM |
Sounds like a solid resolution for the New Year 👌 |
|
Any updates? |
|
I know this is a project of people investing their free time and ressources into. So let me say: thank you for sddm. It really is not taken for granted that you provide us with this awesome piece of software. (And here comes the) But as it is really popular, used in KDE and is like the first interaction one gets with the system. It is very important from a usability and security point of view. Imho development here stalled. I understand that everyone can do in their free time whatever they want to do. I know it sounds hollow to neg because we could stand up and do the work instead of crying. Is it possible to shelter this project under the KDE umbrella? There are a lot more active people and with a planned release cycle. So fixes get shipped timely. PR get a chance to be reviewed and merged. Please - I know I am not entitled to anything - consider reactivating this project. And be it by accepting that one has no interest in maintaining anymore. A very grateful user |
|
Moving the project under the KDE umbrella wouldn't gain much because all the relevant KDE developers interested are here and have commit rights and can give other people those rights. Maybe a company can sponsor the development? That would motivate and push me to review some PRs and get back to SDDM hacking. |
|
@plfiorini maybe you would be open to accept sponsoring via github? I would like to sponsor you if you are open for it :) |
I hope it is possible to generate income from this. For what it is worth, I think if you really want to make it work you should start patreon/github sponsor/etc and most importantly advertise it as much as possible. Regarding the gain of KDEs umbrella I disagree.
Please note I am no KDE dev and everything is only my opinion. I cannot stress enough that I do not want to provocate or put anybody off. Just thinking out loud as the status quo is unsatisfactory imo. @aleixpol Just food for thought |
Feel free to create separate issues both for code location and coordination and also for fundraising. There might be opportunities but I doubt they're huge. As an SDDM dev, I think we'd gain most by adopting certain dependencies to KDE software than by relocating, although I agree that there's always benefits in closely collaborating with a bigger project like KDE. With regards to the issue at hand, I've found some time to fix some leftover issues I knew were present in our implementation. I'd like to encourage testing of current |
|
3 years and no release. I would love to see an alternative that integrates with KDE wallet |
|
@SingYankee 2.5 years even, but spamming email of 20+ people isn't going to help push things forward. |
|
Why don't SDDM devs just release right now? Screw the regressions, isn't that what point releases are for? The master branch works way better than the normal release anyway. |
|
Yes, I think the same. People not using Arch should suffer. Release a version and forget about the problem. Otherwise, everyone will be just as bad for a long time :( |
|
I'm probably not helping by adding to the spam here, but maybe SDDM should switch a versionless update model? Rather than seeking perfection by resolving all regressions before tagging, put the onus on the distributions to apply patches or reverts as needed to get the desired behavior on their end. This might sounds like a bad idea at first take, but it's clear to me the maintainers of the major distributions have more time to get things right than the developers. Given the resource differential, I don't see a problem with a change like this. It will also clear up what distributions should be chasing, latest master/develop or the latest tag of the repository. I'm personally using sddm-git from the Arch AUR and update it periodically on all my systems. It fixes some odd lingering bugs that have been fixed for literally years. If things don't change in the next year, I'm assuming most distributions will also begin probably consider just following the develop branch and ignore any "releases" that come out anyways. |
|
Fedora already does this. It uses git-hash version model specificaly for SDDM because (i think) of Wayland Default SDDM initiative =) |
|
I would assume that most (hopefully all) distros which ship 0.20.0 don't just build it vanilla but apply fixes on top. |
I think at least one patch is required if you don't want the XDG to crashloop on login. There's a couple of build fixes that are probably required too depending on the versions of other things. |
That's a terrible idea. It's what distributions do on the worst case scenario but if every project did that it would be a nightmare for distros. If git master + a couple of patches is better than stable releases (and it really is in the case of sddm) then upstream should take courage and do the only sane thing to do: release a new version despite the known issues. |
We'd need a 0.20.1 for that, but so far SDDM didn't put in the effort to maintain stable branches. Then the issue is that some actually want features and not just bugfixes... |
Dealing with stable branches is not hard when you don't have to offer any kind of long term support. On the contrary you can branch just to backport a couple of fixes later.
That's because these features have been laying in the main branch for years: it's frustrating and understandable. |
So sddm hanging 1m30s when shutting down and not seeing sddm when booting with 2 monitors are features now |
$ pacman -Q | grep sddm
sddm 0.19.0-9
sddm-kcm 5.27.2-1I haven't had that shutdown issue in 1-2 years, it's not I am running EndeavourOS with X11. Perhaps your distro has older packages that aren't An older install may also have the latest updates, but left original config alone (this can happen with packages installed too IIRC). A good example might be when Plasma changed to systemd boot service, maybe that's what resolved it for me and for you on an existing install you were not switched after the update? EDIT: Usually if you experience a bug, you should report that, and if you're going to cite it in an issue like this, then link to that report. If you searched Github Issues (or the KDE bugzilla), you'd find this is already done with plenty of users chiming in. They share workarounds (systemd config to lower the time), others use
I run with two monitors as well, although I have autologin enabled so I can't comment on that much. Both displays seem to handle boot to desktop just fine though. NOTE: If you want to discuss this further, ping me from an appropriate issue, not this one. Anyway, I have been getting a tonne of notifications on this issue recently but often it's nothing regarding progress, or contributing anything of value to the issue as an update. The repo continues to see active development (frequent commits). Yes a proper release would be great, but all you're doing adding another comment here that doesn't add value and annoys many that are subscribed. 👍 the issue description at the top, click "subscribe" on the right, and then wait with everyone else or get involved with development to resolve it sooner. If your comment doesn't add value (complaining it's not released, asking if there are any updates when the issue is open and no new release, etc), please stop. Take that to a community discussion instead, not an issue tracker. |
|
I know all this, that's why I switched to sddm-git, but checking again and it seems my 2 monitors problem isn't actually fixed so I'll open an issue. |
No. But rootless X or wayland greeters are. |
|
I know "pls make a new release" is annoying and I apologize for it, but is it possible to make a 0.19.1 release that includes a fix for the 90-second-shutdown bug? I am currently working around this by installing |
Do you know which commit fixed that? |
|
I suppose this is it. |
|
The 1.5 year existence of this thread is indicative that this project could use an additional maintainer dedicated solely to handling interim releases. This would free up the existing maintainers to focus on the next generation of sddm and reviewing pull requests, while also releasing bugfixes. It's abnormal to treat this as an "either or". There are several sddm bugfixes, like the one mentioned above, that are already merged. We need a dedicated maintainer to handle bugfix releases. I would be happy to take this on, but I doubt I'm the best candidate. In any case whether it's me or someone else, that role needs to be filled as this isn't just about 19.1, it's about 19.2, 19.3, 20.1, etc. |
|
SDDM is approved (at least on the side of KDE) to become part of KDE brand and it should follow more regular release schedule soon. |
|
Oh yeah, such a cool news. SDDM REALLY needs more love and faster releases schedule. Fedora does not suffer from using old SDDM, because it uses git version, but many distros do. |
|
I also do support the idea to sponsor the current maintainer of sddm and leave the project at itself and don't put it under the organizational KDE umbrella. I assume that sddm is big and important enough that some donation options (please don't use Microsoft GitHub for that) would make it possible to make a living for one developer. |
|
One does not exclude the other, but honestly the choice of going under the KDE umbrella or not belongs only to Pier Luigi. |
|
I also wonder if the KDE people still have commit rights in this repo here why they don't commit? |
|
KDE has graciously offered to pull SDDM under its wing. You say you support leaving the project as-is, outside of KDE. And yet you give almost no rationale for why you prefer that. It's a bit rich to, after 3 years of no releases on this project, hop in and say "did you think about donations?" and not only that but instruct the maintainers on what donation mechanisms they should and shouldn't use. The richness of that aside, your proposal has already not worked for sddm. It's been 3 years since a release. The maintainer mentioned donations already earlier in this thread. It never happened. Your comments come across as an idealistic imposition of ideology, and not a practical understanding of the current state of sddm. KDE adopting sddm is a breath of fresh air and should be for anyone who's been waiting for an sddm release these past 3 years. |
I would say your observation might be correct.
OK, then just asking for my learning because I'm not well experienced with "managing" FOSS projects. Why isn't KDE just forking SDDM? It is GPL software. No need to ask. Just do it. Or if there are KDE developers with commit rights why don't they (friendly) take over the repo and create a new release? Or why using SDDM? Why not one of the other alternatives? I just asking for my learning. ☮️ |
There is no legal requirement to ask, but as a matter of respect for the original maintainer's wishes and as a matter of practicality, it's preferable. For one thing, having a forked version would be a huge drag if commits were still being pushed to the original repo. KDE would spend more time pulling in commits from the old repo than anything else. We're also all working in the same sandbox here. The spirit of the GPL is that we're all collaborating together and sharing our work. Aggressively taking over a project without the maintainer's approval, while permitted by the license, would be both impractical and a violation of the spirit of the GPL.
SDDM good :) it's also become the defacto standard DM for KDE. There used to be KDM, but now to my knowledge there is no de jure official DM. Adopting SDDM would make what is currently a de facto standard the de jure standard. |
|
I totally agree with what you wrote about the GPL spirit. I feel it the same way and always try to handle it that way for myself. It always helped me lot with the former maintainers in my back as counsellors for example. But "3 years no release" sounded to me a bit like "the project is dead" or "no reaction from the maintainer". |
No release is not the same thing as dead. The last commit to master is from april. No release means that although master has bugfixes for 0.19, there are regressions and new features as well. This complicates things. The codebase has diverged from how it was in 0.19 in a way such that individually cherry-picking those fixes into a separate release at this point wouldn't make a whole lot of sense. The state of sddm isn't that it's dead, since in terms of contributions it's very much alive. It's moreso that the maintainers lacked bandwidth/funding/interest in maintaining bugfix and point releases. That's completely understandable, but it leaves the project in a state where the release cycle needs to "start over" so to speak. I think KDE can provide the infrastructure and processes to manage release cycles, timeline management, and standardization, while freeing up the maintainers to hack away at sddm :) which is why I'm hopeful that there's agreement from all parties here. |
|
Thanks for the interest and input everyone. I think that we've generated enough noise for developers and maintainers to consider the topic - as indicated by this issue https://invent.kde.org/plasma/plasma-desktop/-/issues/91. I believe the KDE community will do a great job with project planning/releasing, so I believe we can close this issue. That said, thank again everyone o/ |
and others
Looking at the past few releases - looks like sddm is having one roughly every year. With the last one in Nov 2020.
At the same time the 0.20.0 milestone tracker lists 11 outstanding and 42 addressed issues. Handful of the outstanding ones are fairly old (2015, 2017 anyone) and there is seemingly no traction there.
So my question is - would it make sense to trim down the milestone to regressions and other issues actively being worked on? This way we can get a release out sooner, so people can enjoy features like rootless X sooner than later?
@plfiorini what do you think?
The text was updated successfully, but these errors were encountered: