Re: GNOME and non-linux platforms (release team please stand up)
Jason D. Clinton, Wed, 22 Jul 2009 14:06:36 -0500: Obviously the alleged pointlessness of something that we are arguing about is relevant. I think the pointlessness (isn't it a beautiful word? :)) of flaming Sun is that the argument was not just about Solaris. Platform independence is a good thing for other platforms (*BSD/Mac?/Windows?) in itself. Matěj ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME and non-linux platforms (release team please stand up)
Hi, FWIW, I've been advocating for a while that, for example, GStreamer should aim to provide everything an application needs - ie. a complete framework. This came up when Cheese was being ported from HAL to use libgudev for device discovery. Now, the actual device interaction already happened in GStreamer, e.g. you use the v4l source and pass it a device file. But device detection etc. was missing. Having all that in GStreamer will make Cheese easily portable to Solaris, Windows, OS X and so on (and AFAICT these changes are happening in GStreamer so kudos to these guys). Funny you should mention this cause the GStreamer team had some discussions with Alexander Larsson among others about having glib support for device detection. I guess the conclusion is that also the GStreamer devs agree a cross platform device detection setup would be nice, but I guess there is still some disagreement on where it belongs :) Anyway, I like your suggestion for the 3 tiered stack as it should give everyone involved a clear idea about what the GNOME community will undertake to ensure works across all platforms and what the OS communities themselves need to take care of. My hope is that someone like the release team would issue a statement with what our guidelines are currently, in relation to these issues, as I feel we are in a very freewheeling stage now where the boundaries for when platform specific stuff is a feature and when its a bug is constantly changing. Adopting something along the lines of your proposal would help clarify the situation and people working on Solaris and FreeBSD for instance would at least have something clear to work from. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME and non-linux platforms (release team please stand up)
Jason: Obviously the alleged pointlessness of something that we are arguing about is relevant. Whether or not there are--you know--actual people using said OS is what this is really about. And apparently even Sun doesn't think so since they no longer invest the same level of resources in it that they once did. I'm calling a duck a duck here. It's a failure and even Sun knows that it is. There's no reason we shouldn't be scrambling a few eggs on Solaris to advance the Linux desktop experience. I didn't realize that Sun was the only company involved with GNOME that has had resources negatively impacted by this long-standing downturn in the economy. Even though, it is true, Sun does have fewer resources working on GNOME than we did several years ago, there are still several dozen engineers at Sun working on GNOME and GNOME-related technologies. Recently Sun has been focusing a lot of time and energy into making a new accessible installer, the Time Slider GNOME ZFS integration application, adding better wireless and printing support, improving the multimedia experience, and lots of other things. The latest releases of OpenSolaris have been well received, I think because we are doing a good bit of work making GNOME available on Solaris. http://blogs.zdnet.com/perlow/?p=10250 Sun is already working to add DeviceKit support to Solaris, GNOME runs fine on Solaris without PulseAudio. Sun does not have much of an interest in shipping modules which have a strong dependency on PolicyKit (e.g. Sun is moving to use VisualPanels instead of wanting to ship GNOME system tools), and it typically isn't hard to make those few programs that use PolicyKit that we do want to ship use RBAC instead. I am not sure what the big deal is here. Nobody from Sun has been complaining about GNOME being too Linux-ey, have they? Sun has always had a good relationship with the GNOME community, and it has never been particularly hard to get patches upstream to support things needed for GNOME to work well on Solaris or OpenSolaris. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME and non-linux platforms (release team please stand up)
Am Mittwoch, den 22.07.2009, 14:21 -0400 schrieb Tristan Van Berkom: On the other hand, its possible we could do better tracking this stuff, is there a l.g.o. page that I can visit that shows me what are the blocker bugs in the platform for any given supported system ? bugzilla.gnome.org provides a portability keyword and you can set the severity of a bug. I don't think that a wikipage is needed. If people use these bugzilla options is another question though... andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME and non-linux platforms (release team please stand up)
On Thu, Jul 23, 2009 at 2:36 AM, Matej Cepl mc...@redhat.com wrote: I think the pointlessness (isn't it a beautiful word? :)) of flaming Sun is that the argument was not just about Solaris. Platform independence is a good thing for other platforms (*BSD/Mac?/Windows?) in itself. I agree with you with one small distinction: OpenSolaris and *BSD need a whole other level of platform independence that OSX and Win32 do not. One doesn't need a panel/shell/nautilus on OSX and Win32 (from here on in, application target platforms). Our application target platforms don't need DeviceKit, PulseAudio or a sound mixer applet with a abstracted mixer backend. They don't need gnome-settings-daemon running to handle triggering screen saver or DPMS events. Or to toggle backlights with a gnome-power-manager. We cover 99.9% of computer users' platforms on the face of the earth by expending our limited resources on Linux, OSX and Win32 (and increasingly mobile Linux via G* stack). And we don't sacrifice our free software principals in the process. In the (unimportant) module that I maintain, for example, there are #ifdef's all over the code for Win32 support and I'm happy to accept patches for it. However, we are in the process of pursuing the re-thinking of some core cool features and other platforms have likely suffered as a result. There would be no Clutter port of five games in the module if we had pursued the strategy of installing seven VM's and testing all our changes on all of them. It would be years yet, before they were available. No GSoC student would have the time to do the seven VM's strategy and still achieve their summer coding goals. There would be no telepathy tubes multiplayer support on the way. We just don't have those kinds of resources. David Zeuthen's eloquent explanation of the don't preclude portability but leave the back-end work up to those who want it philosophy is spot-on. On the other hand, two free software platforms do need this major extra effort on the part of everyone who maintains a GNOME module: OpenSolaris and *BSD (here on in, desktop target platforms). These platforms want all of the things mentioned above. Unfortunately, from the perspective of hands to do the actual work, the fact of the mater is that neither of the two platforms have a lot of users. On the *BSD side of things, the desktop-related driver situation is lamentable. However, *BSD has a huge thing going for it: vast parts of the user space are nearly identical to Linux. So with exception given to the absence of udev, it really isn't all that different. Indeed, there is even a semi-official *BSD kernel for Debian. OpenSolaris, however, suffers from a legacy of esoterically cathedral-like design on some fundamental sub-systems. The work to make all the things mentioned above work is so, so much more than any other platform for GNOME. I'm fairly confident in saying that Win32--if it isn't already working in 2.27.x--would be a trivial amount of additional effort for GNOME Games. And while OSX still looks quite ugly and *BSD lacks good 3D drivers, they too would continue to be a somewhat minimal amount of effort. As for OpenSolaris, who knows. I have examined the packaging of GNOME Games in OpenSolaris in the past and was not encouraged by what I saw. And I don't even maintain a module that really cares all that much about the underlying plumbing. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME and non-linux platforms (release team please stand up)
Morning folks ;-) On Thu, Jul 23, 2009 at 7:08 AM, Andre Klapperak...@gmx.net wrote: Am Mittwoch, den 22.07.2009, 14:21 -0400 schrieb Tristan Van Berkom: On the other hand, its possible we could do better tracking this stuff, is there a l.g.o. page that I can visit that shows me what are the blocker bugs in the platform for any given supported system ? bugzilla.gnome.org provides a portability keyword and you can set the severity of a bug. I don't think that a wikipage is needed. If people use these bugzilla options is another question though... Maybe a query into the GNOME bugzilla database will give me the impression that GNOME is taking care of my issues on my system foo, Maybe the same bugzilla query could be useful to me as a developer`s roadmap to addressing problems on system foo, but I doubt it. On the other hand people do file these bugs, so there is evidence that people do care about the bugs - and somebody might even be interested in volunteering to track them; so that we could have a report of the status of the platform on a given system, it might even be useful for us maintainers to have a clearer picture of what is going on with our code when distributed in the real world. Usually in the past Ive had time to go over the buglist before release time and nail all the blockers I can, this hasnt been the case this year, and really as far as I am concerned as a maintainer, its really pretty and nice to set patch status and stuff like that, but a bug is unconfirmed until its resolved - thats the summit of interaction with bugzilla I can realistically afford. Cheers, -Tristan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
