On Tue, 2012-10-23 at 07:26 +0200, Bastien Nocera wrote: > I don't see how this helps. The code just lives somewhere that's still > within view (gnome-desktop isn't some magic module where things get > hidden),
But I'm also volunteering to help keep it compiling and at least the systemd case tested. You're *really* rejecting this based on the premise that the CK code would exist somewhere in GNOME and it's too much of a burden on you to ever even look at it? At least Florian's reply earlier in the thread implied that he thought centralizing the logind/CK burden would be a good idea, and I'd take that to mean he would spend a bit of time helping out. I just ran "git log gnome-settings-daemon/gnome-settings-session.c" in the gnome-3-6 branch. You have *never modified this code*. It's Richard, Rodrigo, Federico, and Matthias. So I'm dubious about a claim that this code is so dire that you can't even be bothered to have a dependency containing it. > gnome-settings-daemon's power plugin still requires logind to > work, Now in contrast to the "session is active" code, this is a complex codebase; 5000 lines is nothing to sneeze at. Also, this bit is special to g-s-d, unlike the "session is active" bit which a number of other modules (gnome-shell e.g.) also need to query. So it seems to me well within your rights as maintainer to say "only systemd is supported here". > and gnome-shell with upower/ConsoleKit will likely behave brokenly > (given that there's no gnome-settings-daemon counter-part). But the point is that we're not *regressing* anything for the CK case. Sure, GNOME in the CK case will have bugs. That's fine by me. GNOME has plenty of bugs, some of them even very embarrassing. > What's the sudden attachment to ConsoleKit? You could just as easily 1) > port to g-s-d logind code to use D-Bus, and write a shim on top of > ConsoleKit that would export a similar API. I took the previously working code. It's not clear to me what benefit the changes you're talking about would provide other than turning compile-time detection into runtime detection, which is kind of useful but not of critical importance. So what's the path forward in your eyes? Are you still suggesting that GNOME immediately delete all CK code? To be clear, my proposed plan is: * Spend a little bit (not necessarily a lot) of effort to avoid regressing CK. * It's OK if new features or bugfixes rely on logind. * If particular complex functionality like the g-s-d power plugin gets too hard to map to both CK/logind, announce that in advance, give a warning that code will be deleted, if no one steps up to help, delete it. _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
