Development: New module decisions for 2.28

view full story

http://permalink.gmane.org – Hi, The release team met on Sunday to see how sunburnt the various members were. There were certainly big differences. Andre was bright red, while some who shall stay anonymous were, hrm, untouched by the sun. Afterwards, we managed to find a few minutes to discuss the new module proposals. Many thanks to the people who contributed to the discussion on the list, and to the authors and maintainers of the proposed modules! Short summary ============= In: gnome-bluetooth (desktop) gnome-disk-utility (desktop) libgdata (external dependency) libseed (bindings) DeviceKit-disks (external dependency) WebKit/GTK+ (external dependency) libchamplain (external dependency) Out: krb5-auth-dialog icontool General note about the hal migration: some modules (like rhythmbox/banshee, even if not part of the GNOME modulesets) will rely on udev in the future. This means they will need some work for non-Linux-based OS. Help is needed to make sure this migration goes smoothly for those platforms. Details ======= + gnome-bluetooth (desktop) - good doc, even an experimental port to mallard - works great => approved => bluez becomes an approved external dependency => has a runtime dependency on obexd + gnome-disk-utility (desktop) - stub documentation for the palimpset utility - replaces gfloppy (in gnome-utils, already removed) - needs a string review (techy ones, missing comments, etc.) . Matthias can work with David on it next week - Linux-only for now (but this is more related to DeviceKit-disks) - optional dependency for gvfs right now - provides libraries with no guarantee for API/ABI stability => approved => non-Linux-based OS won't be able to use it unless DeviceKit-disks is ported there. We encourage people to work on those ports to offer the best experience to GNOME users on those OS. + libgdata (desktop) - good api doc - required for the current version of totem youtube plugin, and maybe later by evolution - some worries about the protocol being only used by Google at the moment (on non-free services) - we certainly want to allow users to access their data, though - technically not needed in the desktop => approved as external dependency + krb5-auth-dialog (desktop) - reactive maintainer - minimal doc - suggestion to integrate it in seahorse or gnome-keyring - no reply from the community - neat tool, but that's not something that end users will directly install themselves. => rejected because it doesn't really fit the desktop set => suggestion to integrate it in seahorse, though + libseed (bindings) - was mainly rejected because of gjs vs seed for 2.26 - gnome-js-common was created to offer a common js module between gjs and seed - still, for reasons that are independent from the gjs and seed teams, there are technical differences that makes it hard to write code that can be used with both gjs and seed - gnome-shell will likely stay with gjs, but seed people offered to port it to seed - we want people to start using js in GNOME now since it will likely play an important role for the future => approved => people should write code that also works on gjs when possible, since we might later decide that gjs is more appropriate + DeviceKit-disks (external dependency) - clearly the right way forward - DeviceKit-disks is not yet available on non-Linux systems - it requires recent udev & kernel - many things can already be done with gvfs only (no need for hal or DeviceKit-disks) => approved => it's preferred to keep a hal backend when possible (instead of just removing it) for portability reasons + WebKit/GTK+ (external dependency) - good work done to fix issues - still not perfect for accessibility . we trust the WebKit/GTK+ team for fixing this => approved => the WebKit/GTK+ team needs to continue work on accessibility => modules with WebKit ports should merge the relevant branches (eg, yelp) + libchamplain (external dependency) - people like it - needs to be ported to clutter 1.0 => approved if ported to clutter 1.0 + icontool (external dependency) - no reply to the mail by Frederic (on June 10th) - should replace icon-naming-utils - mostly useful for one-canvas work (but from discussion with artists, it's not completely ready yet) - would the icontool-render be used during "make dist" or "make install"? => rejected as it's not really needed now and we didn't get replies to questions (it will probably be accepted when it's ready) Thanks, Vincent (Software)