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