[desktop-discuss] GNOME 2.22 [LSARC/2008/207 FastTrack timeout 04/02/2008]
Irene Huang
Irene.Huang at Sun.COM
Wed Apr 2 10:05:45 PDT 2008
some minor interface changes provided by the project team.
Please raise issues if any.
--Irene
On Wed, 2008-04-02 at 01:12 +0800, Irene Huang wrote:
> Hi,
>
> The time out for this case is today. As agreed in the LSARC meeting
> today, I am going to close this case if no further issues are raised
> within 24 hours :)
>
> Thanks
>
> --Irene
> Irene Huang wrote:
> > Hi, Brian
> > On Wed, 2008-03-26 at 13:04 -0500, Brian Cameron wrote:
> >
> >> Irene:
> >>
> >>
> >>> You are correct that the interface taxonomy are not related to the
> >>> support model. However, it seems that many ARC cases don't include the
> >>> support model. There's no area for us to specify the support model of a
> >>> module in the ARC one-pager template.
> >>>
> >> ARC has a sort of black & white worldview. If it's Volatile or higher
> >> then it is supported. If it is Private, then it is not supported. ARC
> >> does not support the idea of providing interfaces that are not supported
> >> for end-users or developers to play with.
> >>
> > I don't think this is correct. Support levels and interface stability
> > are not mapped to each other. However, this doesn't affect this case.
> >
> > We've agreed to notify the users about the support level using "release
> > notes" or "manpages" (which you mentioned in the latter part of the
> > mail). :)
> >
> > --Irene
> >
> >>> What's your suggestion about how to make it clear to the users that some
> >>> of the interfaces are not supported.
> >>>
> >> All interfaces that are Volatile or higher need to be supported.
> >> Volatile means that interfaces may change. However Volatile does not
> >> mean "We won't fix a legitimate bug in the code because the module
> >> is Volatile." Volatile only means that an interface change is not
> >> considered a problem or a bug. You obviously can't really claim that
> >> the introduction of a bug is an "interface change".
> >>
> >> Normally any issues or warnings about how people should use interfaces
> >> are communicated in the manpage. If you really do not want people to
> >> use an interface, it should clearly be marked as Private.
> >>
> >> Note that interfaces which are missing manpages, or which are missing
> >> an ATTRIBUTES section in the manpage leave it up to the user to guess
> >> what the interface stability level or support level should be. This
> >> can be especially confusing for the user if there are API docs on the
> >> web which explain and/or encourage people to use the interfaces.
> >> There are several expamples of Volatile interfaces in the JDS stack
> >> which have installed API docs in /usr/share/gtk-doc, but are missing
> >> manpages, for example.
> >>
> >> So if we don't have a manpage clearly marking an interface as Private
> >> and a user depends on the interface, and finds a bug, or if the
> >> manpage doesn't highlight an interface as Volatile and a user runs
> >> into a problem because the interfaces change; then the project team
> >> might easily get stuck having to fix the issue for the end user.
> >>
> >> In other words, if we don't communicate the interface stability level
> >> to the end user, then we aren't really helping the end-user, nor are
> >> we protecting ourselves from having to fix issues in areas of the code
> >> which are not intended for end-use.
> >>
> >> > BTW, quite alot of the desktop components are "managed supported"
> >> > which means that we will follow the community. And "managed Supported"
> >> > is somehow the default support model for the projects that the desktop
> >> > team port from the community. Unless for some special cases, e.g.
> >> > Firefox.
> >>
> >> Does "managed supported" really have any meaning? If we just "follow
> >> the community" this may be "managed" but doesn't sound like "supported"
> >> to me. I thought Sun's policy was that we support all non-private
> >> interfaces.
> >>
> >> In Solaris 10, I remember the JDS team tried to claim several programs
> >> we "unsupported" such as gimp, GOK, gnopernicus, etc. and we hid them in
> >> /usr/jds/bin. ARC made us do away with this practice in Nevada because
> >> (I thought) Sun doesn't ship non-supported stuff.
> >>
> >> Am I just confused, or is Solaris diverging from having a consistent
> >> interface and support model story?
> >>
> >> Brian
> >>
> >>
> >>
> >>
> >>> On Tue, 2008-03-25 at 14:56 -0700, John Fischer wrote:
> >>>
> >>>> Jedy,
> >>>>
> >>>>
> >>>>
> >>>>>> Are we documenting the extreme volatility of libgweather? How
> >>>>>> are we letting our developer base that the interface is "not
> >>>>>> supported"?
> >>>>>>
> >>>>> I do not quite understand what you mean by "extreme volatility of
> >>>>> libgweather". Do you mean libgweather changes too often?
> >>>>>
> >>>> These interfaces will change at any point in time. They will change
> >>>> so frequently that we won't even support the interface. Other Volatile
> >>>> interfaces are still supported by Sun.
> >>>>
> >>>> I have looked at a couple of the other replies to this issue and it
> >>>> would appear that people are again associating support/non-supported
> >>>> with the interface taxonomy. Just because something is declared
> >>>> Volatile does not mean that it is not supported. In fact there are
> >>>> many Volatile interfaces that are supported by Sun. We need to make
> >>>> sure that our developers know that this interface in particular is
> >>>> not supported. We need to update the man page to state that the
> >>>> interface is not supported.
> >>>>
> >>>>
> >>>>>> The fast track states that there are no Removed Components (3.1.5).
> >>>>>> However, the interface table appears to list several removed
> >>>>>> components:
> >>>>>>
> >>>>>> gnome-accessibility-keyboard-properties
> >>>>>> gnome-pilot-make-password
> >>>>>> gnome-menu-spec-test
> >>>>>> test-control.py -- minor
> >>>>>> liborg-gnome-new-mail-notify.so
> >>>>>> gpilotd-session-wrapper
> >>>>>> ext_rehashdir.py
> >>>>>> ipy_profile_sh.py
> >>>>>> ipythonrc-scipy
> >>>>>> desktop_gnome_applications_help_viewer.schemas
> >>>>>> check-ptp-camera
> >>>>>> nautilus-connect-server
> >>>>>> mapping-daemon
> >>>>>> libmapping.so
> >>>>>> gestures.so
> >>>>>> xdg-user-dirs-update.desktop
> >>>>>>
> >>>>>>
> >>>>>> Which document is correct? I am mostly concerned with those things that
> >>>>>> are in /usr/bin. However, customers might also be using the others in
> >>>>>> one form or another.
> >>>>>>
> >>>>> [3.1.5 Removed Components] section intends to mention removed modules
> >>>>> not removed interfaces. But the items in the above list are all
> >>>>> interfaces. So we did not mention them in section 3.1.5.
> >>>>>
> >>>> Right. So as a committee we are interested in interface changes and not
> >>>> modules. These are interfaces that are being Deprecated in the previous
> >>>> release and removed in this release. What type of notification is being
> >>>> done for these interfaces? In particular the interfaces that might be
> >>>> used in a script by a local system administrator? Even if these
> >>>> interfaces are Volatile it would be beneficial for our customers to know
> >>>> when the interface is removed.
> >>>>
> >>> Usually, I guess this should be included in something like release
> >>> notes, shouldn't it? My idea is that the customers don't have access to
> >>> the ARC materials, therefore, they won't know it if we put it in the
> >>> interface as obsolete. Or by "customer" do you mean internal customers?
> >>>
> >>> Or any good suggestions?
> >>>
> >>> Thanks
> >>>
> >>> --Irene
> >>>
> >>>>> Regards,
> >>>>>
> >>>>> Jedy
> >>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> John
> >>>>>>
> >>>>>>
> >>>>>> Shi-Ying Irene Huang wrote:
> >>>>>>
> >>>>>>> Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI
> >>>>>>> This information is Copyright 2008 Sun Microsystems
> >>>>>>> 1. Introduction
> >>>>>>> 1.1. Project/Component Working Name:
> >>>>>>> GNOME 2.22
> >>>>>>> 1.2. Name of Document Author/Supplier:
> >>>>>>> Author: Jedy Wang
> >>>>>>> 1.3 Date of This Document:
> >>>>>>> 21 March, 2008
> >>>>>>> 4. Technical Description
> >>>>>>> ===================================================
> >>>>>>> GNOME 2.22 ARC Proposal
> >>>>>>> Date: Jan 31, 2008 Jerry Yu <jijun.yu at sun.com <mailto:jijun.yu at sun.com>>
> >>>>>>> ===================================================
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> ===============
> >>>>>>> 1. Introduction
> >>>>>>> ===============
> >>>>>>> 1.1. Project/Component Working Name:
> >>>>>>>
> >>>>>>> GNOME 2.22
> >>>>>>>
> >>>>>>> 1.2. Name of Document Author/Supplier:
> >>>>>>>
> >>>>>>> Jerry Yu (jijun.yu at sun.com <mailto:jijun.yu at sun.com>)
> >>>>>>> Jedy Wang (jedy.wang at sun.com <mailto:jedy.wang at sun.com>)
> >>>>>>> Irene Huang (irene.huang at sun.com <mailto:irene.huang at sun.com>)
> >>>>>>> Brian Cameron (brian.cameron at sun.com <mailto:brian.cameron at sun.com>)
> >>>>>>> Li Yuan (li.yuan at sun.com <mailto:li.yuan at sun.com>)
> >>>>>>>
> >>>>>>> 1.3. Email Aliases:
> >>>>>>> 1.3.1. Responsible Manager: paul.mei at sun.com <mailto:paul.mei at sun.com>
> >>>>>>> leo.binchy at sun.com <mailto:leo.binchy at sun.com>
> >>>>>>> 1.3.2. Responsible Engineer: jijun.yu at sun.com <mailto:jijun.yu at sun.com>
> >>>>>>> jedy.wang at sun.com <mailto:jedy.wang at sun.com>
> >>>>>>> irene.huang at sun.com <mailto:irene.huang at sun.com>
> >>>>>>> brian.cameron at sun.com <mailto:brian.cameron at sun.com>
> >>>>>>> li.yuan at sun.com <mailto:li.yuan at sun.com>
> >>>>>>> 1.3.3. Marketing Manager: Dan.Roberts at Sun.COM <mailto:Dan.Roberts at Sun.COM>
> >>>>>>> 1.3.4. Interest List: desktop-cteam at sun.com <mailto:desktop-cteam at sun.com>
> >>>>>>> accessprogramoffice at sun.com <mailto:accessprogramoffice at sun.com>
> >>>>>>> trusted-jds at sun.com <mailto:trusted-jds at sun.com>
> >>>>>>> gnome222-arc at sun.com <mailto:gnome222-arc at sun.com>
> >>>>>>>
> >>>>>>> ==================
> >>>>>>> 2. Project Summary
> >>>>>>> ==================
> >>>>>>>
> >>>>>>> 2.1. Project Description
> >>>>>>>
> >>>>>>> This project continues on LSARC 2007/520 to provide a newer version of
> >>>>>>> GNOME, as part of the Java Desktop System (JDS), targeted for Nevada.
> >>>>>>>
> >>>>>>> More formally, this project will integrate GNOME 2.22 along with some
> >>>>>>> other components that aren't currently part of the official community
> >>>>>>> release.
> >>>>>>>
> >>>>>>> 2.2. Risks and Assumptions
> >>>>>>>
> >>>>>>> 2.2.1. Schedule
> >>>>>>>
> >>>>>>> This project is targeted to be bundled with Nevada, with an intended
> >>>>>>> integration date of Nevada build 88 (04/07/08), of the current Solaris
> >>>>>>> OS release schedule. This is for a minor release only.
> >>>>>>>
> >>>>>>> 2.2.2. Accessibility
> >>>>>>>
> >>>>>>> Accessibility is still a key concern in the GNOME desktop.
> >>>>>>> Although the community has realized the importance of A11Y, and has
> >>>>>>> contributed a great deal to the project, the core parts of the desktop
> >>>>>>> may not be fully accessible. The project team is adding resources
> >>>>>>> according to need and associating time to market schedules.
> >>>>>>>
> >>>>>>> 2.2.3. GPL Licensed Libraries
> >>>>>>>
> >>>>>>> The following issues are associated with GPL libraries (please find the
> >>>>>>> proposed rule about GPL license libraries here:
> >>>>>>> http://webhome.sfbay/OFR/GPL-LGPLArchRules.html)
> >>>>>>>
> >>>>>>> 1. No LGPL'd libraries should be depending on GPL'd libraries.
> >>>>>>> 2. GPL'd libraries should not be shipped in standard path.
> >>>>>>> 3. Change "GPLv2 or later" to "GPLv2".
> >>>>>>>
> >>>>>>> About the first issue,
> >>>>>>> This issue occurs when a non-GPL (e.g. LGPL) library links against a
> >>>>>>> GPL library. The investigation shows that libgtop is still shipped and
> >>>>>>> libgtop is not depended on by LGPL'd libraries (dependencies include
> >>>>>>> /usr/bin/baobab and /usr/bin/gnome-system-monitor).
> >>>>>>>
> >>>>>>> About the second issue,
> >>>>>>> The GPL rules are still being discussed. We will make sure that new
> >>>>>>> projects with GPL'd libraries are not depended by non-GPL'd libraries.
> >>>>>>>
> >>>>>>> About the third issue,
> >>>>>>> This is a legal issue, and not an ARC issue. We include this
> >>>>>>> information here only for reference.
> >>>>>>>
> >>>>>>> ========================
> >>>>>>> 3. Technical Description
> >>>>>>> ========================
> >>>>>>>
> >>>>>>> This project will build on the base we built with "LSARC 2007/520
> >>>>>>> GNOME 2.20", and provide a newer version of the GNOME desktop into
> >>>>>>> Nevada.
> >>>>>>>
> >>>>>>> The GNOME Project's focus on users and usability continues in GNOME 2.22
> >>>>>>> with its hundreds of bug fixes and user-requested improvements. This
> >>>>>>> project provides many usability improvements, performance tunings,
> >>>>>>> improved configuration, and updated branding. More details on specific
> >>>>>>> improvements can be found on the GNOME community release notes [not
> >>>>>>> yet released]
> >>>>>>>
> >>>>>>> - http://www.gnome.org/start/2.22/notes/
> >>>>>>>
> >>>>>>> Currently, the GNOME 2.22 draft release note is available at:
> >>>>>>>
> >>>>>>> - http://live.gnome.org/TwoPointTwentyone/ReleaseNotes
> >>>>>>>
> >>>>>>> Where possible, we will coordinate with those components that are
> >>>>>>> shipped as part of the official GNOME community release. JDS may
> >>>>>>> deviate from the GNOME community release, but only where there is an
> >>>>>>> appropriate business justification or engineering impact.
> >>>>>>>
> >>>>>>>
> >>>>>>> 3.1. Interface classification summary.
> >>>>>>>
> >>>>>>> In LSARC 2005/734, cairo was defined to be "Unstable". However,
> >>>>>>> it is listed as Volatile in the cairo and gnome-interface manpages.
> >>>>>>> Starting with GNOME 2.22, the JDS team would like to more clearly
> >>>>>>> define cairo interfaces as being Uncommitted.
> >>>>>>>
> >>>>>>> Refer to the LSARC 2005/734 mail log, message dated Tue, 07 March, 2006
> >>>>>>> with the Subject "New LSARC Materials Submitted LSARC 2005/734" for
> >>>>>>> more information about when this interface was defined to be
> >>>>>>> "Unstable".
> >>>>>>>
> >>>>>>> 3.1.1. Changes of Committed interfaces
> >>>>>>>
> >>>>>>> Refer to manpages [5] and gnome-interfaces [6].
> >>>>>>>
> >>>>>>> Minor changes are introduced in GNOME 2.22 for
> >>>>>>>
> >>>>>>> Committed Libraries changes
> >>>>>>> ---------------------------
> >>>>>>> o libglib-2.0
> >>>>>>> o libpango-1.0
> >>>>>>>
> >>>>>>> Committed CLIs changes
> >>>>>>> ----------------------
> >>>>>>> None
> >>>>>>>
> >>>>>>> Committed Configuration Files
> >>>>>>> -----------------------------
> >>>>>>> Starting with GDM 2.22 the JDS team would like to change the
> >>>>>>> interface level of the GDM configuration files from "Committed"
> >>>>>>> to "Volatile". GDM is currently being rewritten and will unlikely
> >>>>>>> use the same configuration mechanisms. Since these interfaces have
> >>>>>>> only been declared as Committed in Nevada, since GDM is not yet the
> >>>>>>> default login program, and since the SXDE/SXCE customer base
> >>>>>>> understands that they are using bleeding edge software and things will
> >>>>>>> change, we feel that the impact will be manageable. Therefore, it is
> >>>>>>> our understanding that the EOF/EOL process does not apply (i.e. no
> >>>>>>> 1 year time, no notice needed).
> >>>>>>>
> >>>>>>> Other changes that are included
> >>>>>>> -------------------------------
> >>>>>>> None
> >>>>>>>
> >>>>>>> Please refer to ./committed-API-changes.txt [4] for details.
> >>>>>>>
> >>>>>>> 3.1.2. New Components
> >>>>>>>
> >>>>>>> The following are new proposed components to be added to the desktop
> >>>>>>> release.
> >>>>>>>
> >>>>>>> ---------------
> >>>>>>> mousetweaks
> >>>>>>> ---------------
> >>>>>>> MouseTweaks is a collection of enhancements to the handling of mouse
> >>>>>>> input in Gnome Desktop environment. It improves general usability and
> >>>>>>> accessibility of a desktop product. It provides more detailed
> >>>>>>> configuration of mouse cursor behavior and a range of accessibility
> >>>>>>> enhancements as well a power-user features, including mouse gestures.
> >>>>>>>
> >>>>>>> MouseTweaks could not be a replacement for current GOK (Gnome On-screen
> >>>>>>> Keyboard). It can be used for motor difficulty users to control mouse
> >>>>>>> cursor, with mouse or Head/Eye tracker, free of click and press&hold
> >>>>>>> action. It works in dwell mode to implement mouse actions (single
> >>>>>>> click, double click and drag&drop). It does not support switch devices.
> >>>>>>>
> >>>>>>> ---------------
> >>>>>>> GIO/GVFS
> >>>>>>> ---------------
> >>>>>>> GIO is the new I/O library for gnome, scheduled to replace
> >>>>>>> gnome-vfs. Its functionality is quite close to the functionality
> >>>>>>> provided by Gnome-VFS. There are a few differences though. The first
> >>>>>>> one is that GIO does not depend on third party libraries, so its use
> >>>>>>> only implies the application to be linked against glib. The second one
> >>>>>>> is that the most complex file system handlers such as ftp or webdav
> >>>>>>> have been moved to a separate application called GVFS. GVFS implements
> >>>>>>> a userspace virtual filesystem. The initial communication between GIO
> >>>>>>> and GVFS is made via D-Bus. It is shipped with glib as a separate
> >>>>>>> library called "libgio-2.0". Libgio contains abstractions for file I/O,
> >>>>>>> file types and things like that. It also contains default
> >>>>>>> implementations for local file I/O. Gvfs uses daemons to handle each
> >>>>>>> mount and D-Bus to talk to these daemons.
> >>>>>>>
> >>>>>>> GIO and GVFS are going to be marked as Volatile for their first
> >>>>>>> releases. Even though GIO is included within the glib bundle, and
> >>>>>>> therefore its API is supposed to be stable, there is still some
> >>>>>>> development and bug fixing going on. In this case, there are odds
> >>>>>>> the community end up being forced to change the API. And our plan is
> >>>>>>> to make them "Committed" in the GNOME 2.24 cycle, if the community
> >>>>>>> demonstrates these remain stable.
> >>>>>>>
> >>>>>>> GVFS includes a FTP, SFTP, Trash, Computer and Burn modules so
> >>>>>>> far. However, the upcoming releases will include more modules that
> >>>>>>> currently are under development such as WebDAV and ObexFTP.
> >>>>>>>
> >>>>>>> GVFS also relies on some trivial libhal functions that debuted in HAL
> >>>>>>> 0.5.10 which will be introduced in PSARC/2008/199.
> >>>>>>>
> >>>>>>> GIO and GVFS will deprecate Gnome-VFS eventually, although there
> >>>>>>> are still quite a few applications that depend on Gnome-VFS.
> >>>>>>> Hence, we will continue depending on Gnome-VFS until all the
> >>>>>>> applications are property ported to the new stack. And we plan to make
> >>>>>>> gnome-vfs "Deprecated" in the 2.22 cycle.
> >>>>>>>
> >>>>>>> ---------------
> >>>>>>> python-numpy
> >>>>>>> ---------------
> >>>>>>> NumPy (Numeric Python) is the fundamental package providing scientific
> >>>>>>> computing with Python. It contains:
> >>>>>>>
> >>>>>>> * a powerful N-dimensional array object
> >>>>>>> * sophisticated (broadcasting) functions
> >>>>>>> * basic linear algebra functions
> >>>>>>> * basic Fourier transforms
> >>>>>>> * sophisticated random number capabilities
> >>>>>>> * tools for integrating Fortran code.
> >>>>>>> * tools for integrating C/C++ code
> >>>>>>>
> >>>>>>> Besides its obvious scientific uses, NumPy can also be used as an
> >>>>>>> efficient multi-dimensional container of generic data. Arbitrary
> >>>>>>> data-types can be defined. This allows NumPy to seamlessly and speedily
> >>>>>>> integrate with a wide-variety of databases. NumPy derives from the old
> >>>>>>> Numeric code base and can be used as a replacement for Numeric. It also
> >>>>>>> adds the features introduced by Numarray and can also be used to
> >>>>>>> replace Numarray.
> >>>>>>>
> >>>>>>> The main reason for adding NumPy is because it is an optional
> >>>>>>> dependancy of PyGtk. With NumPy available, the following PyGtk
> >>>>>>> functions are enabled:
> >>>>>>>
> >>>>>>> When PyGtk is built with NumPy support, then the following PyGtk
> >>>>>>> functions become available for use: get_pixels_array,
> >>>>>>> pixbuf_new_from_array and the pixels.array attribute. Refer here:
> >>>>>>>
> >>>>>>> http://www.pygtk.org/pygtk2reference/class-gdkpixbuf.html
> >>>>>>>
> >>>>>>> So, this improves the ability for Python programs to work with programs
> >>>>>>> that use these PyGtk pixbuf functions. I did a search of programs that
> >>>>>>> we ship that use these functions. At the moment, only the gnome-sudoku
> >>>>>>> game is using these PyGtk functions.
> >>>>>>>
> >>>>>>> -------------------
> >>>>>>> xdg-user-dirs-gtk
> >>>>>>> -------------------
> >>>>>>> Provides GNOME integration for the xdg-user-dirs Freedesktop project.
> >>>>>>>
> >>>>>>> The integration features for GNOME are:
> >>>>>>> - Automatically runs in a GNOME session startup.
> >>>>>>> - Prompt user for a decision on updating of directory names.
> >>>>>>> - Allow user to disable prompting for decision on changes.
> >>>>>>>
> >>>>>>> 3.1.3 Modules previously included in other components
> >>>>>>>
> >>>>>>> -------------
> >>>>>>> libgweather
> >>>>>>> -------------
> >>>>>>> libgweather is a library to access weather information from online
> >>>>>>> services for numerous locations.
> >>>>>>>
> >>>>>>> libgweather is not supported in the devel platform, which means OS
> >>>>>>> vendors won't guarantee the API/ABI long-term, but authors of open
> >>>>>>> source apps should feel free to use libgweather as users can always
> >>>>>>> recompile against a new version.
> >>>>>>>
> >>>>>>> To use libgweather in your code, you need to define the
> >>>>>>> GWEATHER_I_KNOW_THIS_IS_UNSTABLE preprocessor symbol, e.g. by adding
> >>>>>>> -DGWEATHER_I_KNOW_THIS_IS_UNSTABLE to your CFLAGS.
> >>>>>>>
> >>>>>>> ---------------------
> >>>>>>> gnome-settings-daemon
> >>>>>>> ---------------------
> >>>>>>> gnome-settings-daemon has been split from gnome-control-center which
> >>>>>>> was previously a GNOME module.
> >>>>>>>
> >>>>>>> ---------------------
> >>>>>>> totem-pl-parser
> >>>>>>> ---------------------
> >>>>>>> totem-pl-parse has been split from totem which was already a GNOME
> >>>>>>> module. This module provides a simple GObject-based library to
> >>>>>>> parse and save a variety of playlist formats. It was originally
> >>>>>>> written for use in totem, but is now used by other modules, such
> >>>>>>> as rhythmbox.
> >>>>>>>
> >>>>>>> -------------
> >>>>>>> libggz
> >>>>>>> -------------
> >>>>>>> libggz used to be bundled directly with gnome-games (it was added
> >>>>>>> to gnome-games in GNOME 2.18), but is now a separate module.
> >>>>>>>
> >>>>>>> libggz is the GGZ base library, used by the GGZ Gaming Zone server
> >>>>>>> (ggzd), the ggzcore library and other components.
> >>>>>>> libggz provides commonly used functions and low-level communications
> >>>>>>> between client modules and the GGZ server. GGZ interfaces can be
> >>>>>>> used by games to support network gaming features, so that people can
> >>>>>>> play games with other people over the internet.
> >>>>>>>
> >>>>>>> ---------------
> >>>>>>> ggz-client-libs
> >>>>>>> ---------------
> >>>>>>> ggz-client-libs used to be bundled directly with gnome-games (it was
> >>>>>>> added to gnome-games in GNOME 2.18), but is now a separate module.
> >>>>>>>
> >>>>>>> Contains two libraries for the C programming language: ggzcore for GGZ
> >>>>>>> core clients, and ggzmod for game clients. Also, the tools ggz-config,
> >>>>>>> ggz-wrapper and ggzwrap are included. This is currently used by
> >>>>>>> gnibbles, iagno, and gnect - three games shipped with the gnome-games
> >>>>>>> module.
> >>>>>>>
> >>>>>>> 3.1.4. Clarification of GNOME Python interfaces
> >>>>>>>
> >>>>>>> LSARC 2005/506 Support Libraries for the Orca Screen Reader/Magnifier
> >>>>>>> declared PyGtk as "Evolving", PyORBit, and gnome-python as "Unstable".
> >>>>>>> The JDS team would like to clarify that these interfaces have the
> >>>>>>> following interface stability levels moving forward.
> >>>>>>>
> >>>>>>> PyGtk = Uncommitted
> >>>>>>> PyORBit = Volatile
> >>>>>>> gnome-python = Volatile
> >>>>>>>
> >>>>>>> Note gnome-python includes bindings for GConf, libgnome, libgnomeui,
> >>>>>>> libgnomecanvas, libgnomeprint, gnome-vfs, libbonobo, and libbonoboui
> >>>>>>>
> >>>>>>> This is appropriate since all of the above interfaces are Volatile
> >>>>>>> except for GTK+, which is Committed.
> >>>>>>>
> >>>>>>> 3.1.5. Removed Components
> >>>>>>> None.
> >>>>>>>
> >>>>>>>
> >>>>>>> 3.2. Interface tables
> >>>>>>>
> >>>>>>> Interface tables can be found in [3].
> >>>>>>>
> >>>>>>> Refer to the modulediffs [1] report for a list of modules which
> >>>>>>> have been updated to a new version.
> >>>>>>>
> >>>>>>> Please refer to the gtk-docs [8] that are installed to the system
> >>>>>>> with this release of the JDS desktop.
> >>>>>>>
> >>>>>>> Changes to packaging are highlighted in the pkgcmp report. [2] The
> >>>>>>> case materials also includes the list of related pkgmap files for
> >>>>>>> all installed packages. [8]
> >>>>>>>
> >>>>>>> 3.3 I18N Impact
> >>>>>>>
> >>>>>>> It was noticed by the JDS team that many recent JDS ARC Fasttracks
> >>>>>>> were inappropriately specifying "None" or "N/A" in relation to I18N
> >>>>>>> readyness questions. The JDS ARC team has spent the past several
> >>>>>>> weeks working with the G11N team to ensure that all I18N issues are
> >>>>>>> being properly addressed in the JDS stack. No serious issues were
> >>>>>>> discovered in this review, but it became clear that the JDS engineers
> >>>>>>> need to have better communication with the G11N team.
> >>>>>>>
> >>>>>>> For example, we discovered that the G11N was reviewing the C-team
> >>>>>>> mail list to determine which new modules were being integrated,
> >>>>>>> and then they would start working to address any G11N issues.
> >>>>>>>
> >>>>>>> To improve our process, we are now making sure to notify the G11N
> >>>>>>> team more early, when we are preparing ARC materials. This gives
> >>>>>>> the G11N team more time to investigate, do their pre-evaluations,
> >>>>>>> and address any issues. Furthermore, we can include any input from
> >>>>>>> the G11N pre-evaluations on our future ARC forms.
> >>>>>>>
> >>>>>>>
> >>>>>>> ======================
> >>>>>>> 4. Reference Documents
> >>>>>>> ======================
> >>>>>>>
> >>>>>>> GNOME Public Websites:
> >>>>>>>
> >>>>>>> http://www.gnome.org/
> >>>>>>> http://developer.gnome.org/
> >>>>>>> http://www.freedesktop.org/
> >>>>>>>
> >>>>>>> GNOME 2.22 Release Notes:
> >>>>>>>
> >>>>>>> http://www.gnome.org/start/2.22/notes/
> >>>>>>> http://live.gnome.org/TwoPointTwentyone/ReleaseNotes
> >>>>>>>
> >>>>>>> External Dependencies of GNOME 2.21.x
> >>>>>>>
> >>>>>>> http://live.gnome.org/TwoPointTwentyone/ExternalDependencies
> >>>>>>>
> >>>>>>> JDS Engineering Internal Website:
> >>>>>>>
> >>>>>>> http://jds.ireland/
> >>>>>>>
> >>>>>>> GGZ (Gaming Zone), home of libggz and ggz-client-libs
> >>>>>>>
> >>>>>>> http://www.ggzgamingzone.org/
> >>>>>>>
> >>>>>>> Mousetweaks Home Page:
> >>>>>>>
> >>>>>>> https://launchpad.net/mousetweaks
> >>>>>>>
> >>>>>>> Python-numpy Home Page:
> >>>>>>>
> >>>>>>> http://numpy.scipy.org/
> >>>>>>>
> >>>>>>> Xdg-user-dirs-gtk Relevant Link:
> >>>>>>>
> >>>>>>> http://www.freedesktop.org/wiki/Software/xdg-user-dirs
> >>>>>>>
> >>>>>>> Other Related ARC Cases:
> >>>>>>>
> >>>>>>> PSARC 2008/199 libhal support for GNOME 2.22
> >>>>>>> PSARC 2008/164 Move TCP Wrappers from /usr/sfw to /usr
> >>>>>>> LSARC 2008/158 Firefox 3 for Solaris Nevada
> >>>>>>> LSARC 2008/132 id3lib
> >>>>>>> PSARC 2008/122 Python zope-interfaces
> >>>>>>> PSARC 2008/121 Python Twisted
> >>>>>>> PSARC 2008/120 SQLite3.x
> >>>>>>> PSARC 2008/117 PySQLite
> >>>>>>> LSARC 2008/116 XDG User Dirs
> >>>>>>> LSARC 2008/115 Compiz: Compositing window manager
> >>>>>>> PSARC 2008/105 gst-python
> >>>>>>> LSARC 2008/104 XDG Utils
> >>>>>>> PSARC 2008/103 Python XDG Module
> >>>>>>> PSARC 2008/102 Python Imaging Library (PIL)
> >>>>>>> PSARC 2008/101 Gnome Python Extras
> >>>>>>> LSARC 2008/088 libcddb
> >>>>>>> PSARC 2008/084 Python Setuptools
> >>>>>>> LSARC 2008/083 rdesktop
> >>>>>>> PSARC 2008/081 MySQL Python
> >>>>>>> PSARC 2008/078 postrun - delayed execution environment for
> >>>>>>> procedural package scripts
> >>>>>>> LSARC 2008/074 Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana
> >>>>>>> LSARC 2008/068 Libgc for Indiana
> >>>>>>> LSARC 2008/067 Gmime for Indiana
> >>>>>>> LSARC 2008/061 Indiana fast track check list
> >>>>>>> LSARC 2008/059 SQLite
> >>>>>>> LSARC 2008/058 dcraw
> >>>>>>> PSARC 2008/043 Phase 1 of OSS for Solaris
> >>>>>>> PSARC 2008/034 Defining Workstation Owner Infrastructure
> >>>>>>> PSARC 2008/033 Xsun removal
> >>>>>>> PSARC 2008/032 libxml2 upgrade to 2.6.31
> >>>>>>> PSARC 2008/021 HAL Power Management Support
> >>>>>>> LSARC 2007/702 GNOME Power Manager
> >>>>>>> PSARC 2007/685 3-Dimensional driver for ATI Redeon graphics cards
> >>>>>>> PSARC 2007/679 CPUFreq HAL
> >>>>>>> LSARC 2007/657 StarOffice 8 Update 8 bundled into SXDE
> >>>>>>> PSARC 2007/652 Move GNU liby from /usr/sfw to /usr/gnu
> >>>>>>> LSARC 2007/648 Removal of CDE
> >>>>>>> PSARC 2007/635 GNU gettext 0.16.1
> >>>>>>> PSARC 2007/634 More compatibility with GNU gettext in gettext(3c)
> >>>>>>> LSARC 2007/625 vncviewer
> >>>>>>> PSARC 2007/557 GNU libtool 1.5.22
> >>>>>>> WSARC 2007/548 NSPR/NSS/JSS Reclassification
> >>>>>>> PSARC 2007/545 Xvnc
> >>>>>>> LSARC 2007/531 Removal of dtcm
> >>>>>>> LSARC 2007/299 Berkeley Database 4.5.20
> >>>>>>> LSARC 2007/520 Gnome 2.20
> >>>>>>>
> >>>>>>> References:
> >>>>>>>
> >>>>>>> [1] ./modulediffs.txt
> >>>>>>> [2] ./pkgcmp/
> >>>>>>> [3] ./interface-table.txt
> >>>>>>> [4] ./committed-API-changes.txt
> >>>>>>> [5] ./manpages
> >>>>>>> [6] ./manpages/gnome-interfaces.5
> >>>>>>> [7] ./gtk-docs
> >>>>>>> [8] ./pkgmaps
> >>>>>>>
> >>>>>>>
> >>>>>>> =========================
> >>>>>>> 5. Resources and Schedule
> >>>>>>> =========================
> >>>>>>>
> >>>>>>> 5.1. Projected Availability
> >>>>>>>
> >>>>>>> This project will be included in Solaris Nevada.
> >>>>>>>
> >>>>>>> 5.2. Cost of Effort
> >>>>>>>
> >>>>>>> Refer to the PLC documentation which includes P&L for the project.
> >>>>>>>
> >>>>>>> 5.3. Cost of Capital Resources
> >>>>>>>
> >>>>>>> Refer to the PLC documentation which includes P&L for the project.
> >>>>>>>
> >>>>>>> 5.4. ARC review type: [Standard/FastTrack/SelfReview]
> >>>>>>>
> >>>>>>> FastTrack
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> =========================
> >>>>>>> 6. Prototype Availability
> >>>>>>> =========================
> >>>>>>>
> >>>>>>> 6.1. Prototype Availability
> >>>>>>>
> >>>>>>> Development versions of GNOME 2.22 are available here:
> >>>>>>>
> >>>>>>> http://dlc.sun.com/osol/jds/downloads/current/
> >>>>>>>
> >>>>>>> 6.2. Prototype Cost
> >>>>>>>
> >>>>>>> The JDS team works to provide the latest desktop stack in development
> >>>>>>> so that people internally can have access to the latest code for testing
> >>>>>>> and early access to new features. These builds are also used by the
> >>>>>>> desktop team for doing ongoing development and testing. Therefore, the
> >>>>>>> cost of providing the these "prototype" builds are a part of the cost
> >>>>>>> the development team requires to provide the next release of GNOME into
> >>>>>>> Solaris. Since much of the desktop stack is developed externally, the
> >>>>>>> cost of development is shared by many organizations, including Sun.
> >>>>>>>
> >>>>>>>
> >>>>>>> 6. Resources and Schedule
> >>>>>>> 6.4. Steering Committee requested information
> >>>>>>> 6.4.1. Consolidation C-team Name:
> >>>>>>> JDS
> >>>>>>> 6.5. ARC review type: FastTrack
> >>>>>>> 6.6. ARC Exposure: open
> >>>>>>>
> >>>>>>>
> >>>>> ------------------------------------------------------------------------
> >>>>>
> >>>>> _______________________________________________
> >>>>> desktop-discuss mailing list
> >>>>> desktop-discuss at opensolaris.org
> >>>>>
> >>> _______________________________________________
> >>> opensolaris-arc mailing list
> >>> opensolaris-arc at opensolaris.org
> >>>
> >
> >
>
> _______________________________________________
> desktop-discuss mailing list
> desktop-discuss at opensolaris.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: interface-changes.diff
Type: text/x-patch
Size: 3199 bytes
Desc: not available
Url : http://mail.opensolaris.org/pipermail/desktop-discuss/attachments/20080402/559f6143/attachment-0001.bin
More information about the desktop-discuss
mailing list