Hi, all I am closing this project as approved. There're two TCAs which the project team will follow up to implement as soon as possible. 1. Setting Libgweather to be "Private" remove the PC file and header files. Interface table will be updated later on. 2. Implement the encryptions in libgzz and gzz-client-libs, the proposal will be updated to reflect the change.
Thanks --Irene Irene Huang wrote: > 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 >>
