[desktop-discuss] GNOME 2.22 [LSARC/2008/207 FastTrack timeout 04/02/2008]
Irene Huang
Irene.Huang at Sun.COM
Tue Apr 1 10:12:02 PDT 2008
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
>>>
>
>
More information about the desktop-discuss
mailing list