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 >>> > >
