[prev in list] [next in list] [prev in thread] [next in thread]
List: opensolaris-desktop-discuss
Subject: Re: [desktop-discuss] GNOME 2.22 [LSARC/2008/207 FastTrack
From: Irene Huang <Irene.Huang () Sun ! COM>
Date: 2008-03-27 3:28:47
Message-ID: 1206588527.20040.2.camel () goalie
[Download RAW message or body]
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@sun.com <mailto:jijun.yu@sun.com>>
> > > > > > ===================================================
> > > > > >
> > > > > >
> > > > > >
> > > > > > ===============
> > > > > > 1. Introduction
> > > > > > ===============
> > > > > > 1.1. Project/Component Working Name:
> > > > > >
> > > > > > GNOME 2.22
> > > > > >
> > > > > > 1.2. Name of Document Author/Supplier:
> > > > > >
> > > > > > Jerry Yu (jijun.yu@sun.com <mailto:jijun.yu@sun.com>)
> > > > > > Jedy Wang (jedy.wang@sun.com <mailto:jedy.wang@sun.com>)
> > > > > > Irene Huang (irene.huang@sun.com <mailto:irene.huang@sun.com>)
> > > > > > Brian Cameron (brian.cameron@sun.com <mailto:brian.cameron@sun.com>)
> > > > > > Li Yuan (li.yuan@sun.com <mailto:li.yuan@sun.com>)
> > > > > >
> > > > > > 1.3. Email Aliases:
> > > > > > 1.3.1. Responsible Manager: paul.mei@sun.com <mailto:paul.mei@sun.com>
> > > > > > leo.binchy@sun.com <mailto:leo.binchy@sun.com>
> > > > > > 1.3.2. Responsible Engineer: jijun.yu@sun.com <mailto:jijun.yu@sun.com>
> > > > > > jedy.wang@sun.com <mailto:jedy.wang@sun.com>
> > > > > > irene.huang@sun.com <mailto:irene.huang@sun.com>
> > > > > > brian.cameron@sun.com <mailto:brian.cameron@sun.com>
> > > > > > li.yuan@sun.com <mailto:li.yuan@sun.com>
> > > > > > 1.3.3. Marketing Manager: Dan.Roberts@Sun.COM \
> > > > > > <mailto:Dan.Roberts@Sun.COM> 1.3.4. Interest List: \
> > > > > > desktop-cteam@sun.com <mailto:desktop-cteam@sun.com> \
> > > > > > accessprogramoffice@sun.com <mailto:accessprogramoffice@sun.com> \
> > > > > > trusted-jds@sun.com <mailto:trusted-jds@sun.com> gnome222-arc@sun.com \
> > > > > > <mailto:gnome222-arc@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@opensolaris.org
> >
> > _______________________________________________
> > opensolaris-arc mailing list
> > opensolaris-arc@opensolaris.org
>
_______________________________________________
desktop-discuss mailing list
desktop-discuss@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic