On Fri, 2009-07-03 at 16:40 +0100, Richard Hughes wrote:
> 2009/7/3 David Zeuthen <da...@fubar.dk>:
> > On Fri, 2009-07-03 at 16:08 +0100, Richard Hughes wrote:
> >> I'm not going to revert the patch,
> >
> > Then I will revert it if you don't. Seriously, Richard, we are _not_
> > going to go down the wrong path here. I don't know why that point is so
> > hard to get across.
>
> I will remove the patch when intel, radeon and nouveau support
> xbacklight, which ajax seems to think might be sometime in the next
> few months. Apparently intel is already fixed in linus upstream. If
> it's before F12 then we can pretend the interface never existed. If
> it's after F12 then I don't get a billion bugs, all with "my laptop
> brightness worked fine in F11 but doesn't in F12" as the title.
Basically gnome-power-manager (and friends) can just keep using the HAL
interfaces. There's very little point in moving away from HAL if you are
moving to something that is equally bad.
> > FWIW, feel free to keep using the HAL interfaces (X already depends on
> > HAL so HAL will be running anyway), but this patch is just not going in.
>
> You're going to revert it? I thought I was maintaining DK-p? I mean,
> with you triaging all my DeviceKit-power and gnome-power-manager bugs
> you'll totally be aware of the breakage it causes in a distro like
> rawhide.
I don't want to play "who's maintaining what" game, I think we are above
that. But when you want to add hacks/bodges like this and refuse to
remove them, it's time to go to the mattresses, bring out the big guns,
whatever it takes.
The bigger question is not so much who's maintaining each individual
piece of the plumbing subsystems; it's just as much about making sure we
all go in the direction and don't step on each others toes. Adding this
backlight stuff to DeviceKit-power is a bad thing to do since this
belongs in the display server. We all agree on that it seems.
FWIW, I'd expect you to do the same for me, if I added crappy interfaces
to DeviceKit-disks or if Kay added some crap to udev or if the UI in
GNOME for handling disks sucks.
Anyway, it's like this: if we wanted to add hacks/bodges all over the
place, we could have just kept going with HAL. After all HAL is working
great, and it's not like we're abandoning the very idea, we're just
doing things right this time ("plan to throw one away, you will anyway"
- Brooks). We abandoned HAL exactly so we could do things right and move
things out when the new interfaces are ready.
The whole story with HAL and the new stuff coexisting is to ensure
smooth migration paths. It's not an excuse to start screwing around with
the interfaces, it sets a _terrible_ precedent, slows down fixing what
needs fixing (X in this case) and so on.
And the best part of the "this stuff can coexist" story is that it
_actually works_. If we need stuff to move away from HAL, then we add
this stuff in the _right place_.
For example, that's exactly why Kay made libudev LGPL (used to be GPL)
and removed the the I_KNOW_STUFF_IS_UNSTABLE from the public headers.
That's exactly why I wrote libgudev so udev is easy to using from apps
using the G stack. And that's exactly what enable dcbw to move
NetworkManager away from HAL. Because we had all the proper interfaces
in place.
So please revert the patch and let's get on with our lives.
Thanks,
David
_______________________________________________
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel
