[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Fwd: [forum] A strawman proposal for X.org & XFree86.org
From: Vadim Plessky <vplessky () faringosept ! ru>
Date: 2003-03-30 17:54:12
[Download RAW message or body]
Things are going quite fast on recently-announced Forum@XFree86.org.
It seems there is an intention of certain groups (or individuals) to transform
existing developing model of XFree86.
There are some Pros and Cons in existing developing process, but I think KDE
developers should take more active participation in discussion, as we depend
on XFree86 and some changes can be not in favour of KDE.
Please read mailing list archives at:
Archives <http://XFree86.Org/pipermail/forum/>
and subscribe at <http://XFree86.Org/mailman/listinfo/forum> to the ML.
I hope we can influence further developemtn of Xfree86, so that necessary
features would be "in place" and later reused in upcoming KDE releases.
Greetings,
Vadim Plessky
---------- Forwarded Message ----------
Subject: [forum] A strawman proposal for X.org & XFree86.org
Date: Friday 28 March 2003 10:06
From: Alan Coopersmith <alan.coopersmith@sun.com>
To: forum@XFree86.Org
This mailing list is now a week old, and according the pipermail archives has
had 807 posts so far, on a wide range of topics and issues regarding the
future of XFree86, X.org, and X11 itself. It seems some items have reached
a relative consensus while others are still under heated debate. While some
interesting technical issues have been raised, it would seem that the
organizational issues still need to be resolved to provide a framework for
resolving the technical issues in.
We've been discussing some of these issues (mostly around X.org) for quite a
while at Sun, and have collected thoughts from this forum, the X.org
meetings, and our in-the-hallway discussions at Sun into a simple strawman
proposal to try and bring together the organizational issues into something
that can form the basis of further discussion. The following is in no way a
claim at the best solution or one everyone can agree on, or even one
everyone involved at Sun agrees with all the points of, but hopefully it
covers the basic issues that need discussing/clarifying and will give help
shape further discussion. Read it, beat on it and see how it stands up and
where it needs limbs removed or reshaped or new ones attached. Be warned,
there are some parts that some may consider radical reform, especially
involving X.org, and one part involving a rather heinous pun that may cause
physical pain to the reader.
-Alan Coopersmith- alan.coopersmith@sun.com
Sun Microsystems, Inc. - Sun Software Group
Quality, Integration, & Customer Success (QICS)
Platform Globalization Engin. - X11 Engineering
-----------------------------------------------------------------------------
------
Proposal for X.org & XFree86 Direction
Introduction:
=============
A change in the relationship between these organizations has been
under discussion for several years. Additionally, each organization
has recently seen calls for change from both internal and external
parties. The recent call to action has caused the ongoing discussions
at each organization to crystallize and has resulted in this concrete
proposal for the two organizations to follow together. This proposal
has been a long time coming, and owes much to the previous internal
discussions of the X.org Executive Committee and XFree86 Core Team,
as well as to the recent public debate on the forum@xfree86.org mailing
list, and private discussions with members of both organizations.
Current Status & Issues:
========================
X.org is an industry consortium chartered by The Open Group to manage
and enhance the X Window System standards, X Sample Implementation (SI
- currently at the X11R6.6 release) and other intellectual property
that The Open Group acquired when it merged with the X Consortium.
Membership currently requires payment of substantial dues, with the
result that the membership currently consists of 8 companies, plus the
"honorary" member XFree86. Certain "benefits" are only available to
members, including access to the X.org Sample Implementation CVS tree,
bug tracking database, incoming bug reports, and fix reports. X.org
currently has a number of Task Forces covering a variety of areas in
which the members seek standardization or new development (see
http://www.x.org/XOrg_taskforces.html ) and while membership in those
task forces has been opened to the public, this fact has not been
widely advertised, nor have new members been recruited, resulting in
very few participants from outside the X.org membership. As a result,
the task forces tend to have too few active participants to acheive
results in a reasonable time, leading observers to believe X.org is
ineffective. X.org funds go to the running of the organization and
it's task forces, payment to a contractor who maintains the Sample
Implementation & related CVS/bug tracking systems, and to development
of new technologies such as the Media Application Server (MAS -
http://www.MediaApplicationServer.net ).
The XFree86 Project was originally founded to enhance the X SI support
for Unix & Unix-like systems on i386 platforms. Over the years it has
evolved into a full-fledged branch of the X SI, adding enhancements in
many areas outside of hardware support, and supporting a wide range of
platforms. It has become the open source X implementation of choice for
the open source operating systems, and is beginning to be adopted even
by the traditional Unix vendors who previously used the X.org SI as the
basis for their X implementations. XFree86 has a corporate Board of
Directors which manages the corporation and it's assets, but does not
get involved in the XFree86 software development process. The software
development process is managed by the XFree86 Core Team, which selects
new members from the active XFree86 developers as it sees fit. Previously
there was a concept of XFree86 "member", which allowed access to the CVS
repository and private mailing lists, but that has been dismantled with
the opening to the public of read access to CVS and access to the devel
mailing list. Recent controversy has arisen over misunderstandings about
these changes, lack of a public bug tracking system for non-core team members
to know the status of a submitted fix, the small number of people with
CVS commit access, and the process for determining who has CVS access and
what they may commit.
Proposed Future Status:
=======================
X.org
-----
X.org is a non-profit group dedicated to the development and
promotion of the X Window System standards. Membership is open
to anyone who wishes to join the standards development process.
X.org funding provides resources to support the development of
the standards documents, standards compliance tests, and
open source implmentations. It also funds activities
to promote the X Window System and encourage its adoption.
Funding is received from corporate sponsors who benefit from the
continued improvement of the X standards and software.
Sponsorship is not required to participate in improvements, but
does allow access to additional resources and benefits. Sponsors
include operating system vendors who provide X implementations,
vendors who sell X implementations that can be added to other
operating systems, makers of hardware that can be used with X,
and other companies and organizations with an interest in the
continued development of the X Window System.
X.org supports the development of an open source implementation of the
X Window System. Previously it provided its own sample implementation,
but now provides resources to support the XFree86 Project. Those
resources include access to support staff such as technical writers,
lawyers, and other personnel either funded by X.org or loaned from
sponsoring companies.
X.org activities are coordinated through an executive board consisting
of representatives of the sponsors and representatives elected by the
membership at large. The executive board manages the X.org organization
and funds, but has no involvement in technical decisions and standards
beyond the allocation of funds.
Other committees are open to any interested member, and fall into two
categories. The first are permanent steering committees, which manage
an area of the X technology and decide on directions to follow. As
necessary, standards working groups are formed to create a new
standard or revise an existing one. Current steering committees
include Accessibility, Internationalization, Standards Sample
Implementation, and Overall Architecture.
X.org standards include the X Window System itself, and layers on top of
the X Window System, including protocols, low-level and high-level API's,
toolkits, and communication mechanisms between X Window System applications.
Some of the X.org standards are incorporated into The Open Group's Unix
Workstation branding specification.
X.org members may:
- Participate in the creation or modification of X Window
System standards and X.org steering committees.
- Vote in X.org elections or run for office.
Membership is free, and open to any individual who has contributed
to the development & adoption of the X Window System standards
or to a recognized open source implementation.
X.org sponsors may:
- Submit hardware and/or software products to the X.org
laboratory for compliance & interoperability testing.
- Access the X.org lab to debug interoperability problems with
the equipment provided there.
- Participate in X.org publicity campaigns.
- Provide a representative to the executive board
Sponsors may contribute a portion of their sponsorship fee by
donating services to X.org or the open source implementation.
Non-sponsors may submit systems for testing for a fee - for instance,
an enterprise planning a rollout of a certain hardware and software
combination may pay a fee for a one-time test to certify the combination.
X.org is the owner of the X Window System copyrights and trademarks,
and is the latest in a line of organizations that has evolved from
a MIT research project, to an industry consortium, and now to an open
non-profit group. The latest organization was modeled after portions
of the Free Standards Group, GNOME Foundation, and IETF structures.
XFree86:
--------
The XFree86 Project maintains an open source implementation of the
X Window System. There are four levels of participation in the XFree86
software development process:
- User: Can retrieve the latest fixes from the code management system &
access the bug tracking system to file bugs & view bug/fix statuses.
Can submit changes via bug tracking system for maintainers to
review and/or commit. No application is needed - open to all.
- Developer: Same as user, but participates in one or more development
mailing lists (currently devel, fonts, i18n). Has a voice in XFree86
development decisions by contributing to e-mail discussions. No
application is needed - open to all.
- Maintainer: A developer who has been granted access to commit changes to
a specific part or parts of the XFree86 software. Maintainers are
chosen by the Core Team based on a consistent record of contributions
to the project, or the development of a new area the Core Team believes
should be added. The core team may invite a developer to become a
maintainer when they see fit, or a developer can apply to become a
maintainer by e-mailing the core team. Each new maintainer will be
assigned a core team mentor to help with any questions or concerns,
and to monitor the maintainer for the first few months to make sure
they are following the core team policies & standards. Failure at
any time to follow core team policies and standards may result in the
core team removing a maintainer. More than one maintainer may be
responsible for a section of the tree, and some maintainers with an
excellent record and a good amount of experience may be given access
to maintain the entire tree to provide coverage for areas without
their own maintainers.
- Core Team Member: A developer who has a consistent record of contributing
to technical discussions on the developer lists and/or contributing
code changes that enhance XFree86. Most core team members will also
be maintainers, but it is not a requirement - some may prefer to have
a more architectural design role than hands on code contribution.
New members can be nominated by the core team or submit themselves at
any time. A majority vote of the core team is required to add a new
member, but a two-thirds vote is required to remove one for reasons
other than inactivity. The Core Team will be responsible for
maintaining web pages with information for developers wishing to become
involved in XFree86, including a set of standards and guidelines for
code being incorporated into the tree, and for maintainers to follow
when accepting changes.
The XFree86 Project, Inc. also has a Board of Directors for managing the
corporate affairs of the project, but it is not involved in the regular
running of the XFree86 software project.
X.org & XFree86 relationship:
-----------------------------
X.org provides funding and resources as it sees fit for activites to maintain
the XFree86 software. This includes, but is not limited to, development of
new features, documentation of existing interfaces, testing and maintenance
activities.
Upon the release of X11R6.7, XFree86 shall integrate the X11R6.7 code
into their code management system as the base of the "X.org Standards
Sample Implementation" (SSI) branch. The X.org SSI committee shall
assume responsibility for managing the tagging of this branch. An
initial review shall be performed comparing the differences between
the SSI branch and the current XFree86 branch, and then ongoing
monitoring will occur of differences between the two branches. The
X.org testing laboratory shall perform regular compliance test runs on
the SSI branch and the proposed addtions. Bug fixes that do not change
any interfaces may be tagged for incorporation into the SSI branch
upon review by at least one SSI committee member and verification that
it does not cause failure of the compliance tests. Changes that
affect public interfaces (programs, API's, command line options,
extensions, protocols, etc.), but do not change any published standard
or introduce any new API or protocol/extensions, may be tagged for
inclusion in the SSI branch after an e-mail review by the SSI
committee, and will be automatically approved unless an objection is
raised within two weeks by a committee member. Changes that would
change an existing standard or require the adoption of a new standard
will not be incorporated into the SSI tree until approved by the X.org
Architecture committee. Regular releases of the X.org SSI will be
organized and managed by the SSI committee.
This will allow those who want to follow the latest innovations to use
the XFree86 branch, while ensuring standards compliance and increased
stability for those who still wish to follow the SSI branch.
Process Examples:
=================
User Fox is convinced that the truth is out there and that everyone should be
helping in the search for alien intelligence. To do this, he wants to add
a new extension to X, the "Force Idle Loops to Execute SETI@Home" extension
(X-FILES), which he wants to become a recognized X standard. There will be
two paths to doing this:
Path A (Code Speaks):
1) Fox mails devel@xfree86.org with his proposal. Details are hashed out,
and a 0.1 implementation is written. Fox is now an XFree86 Developer.
2) Fox submits his changes via the XFree86 bug tracking system, where they
are reviewed by a maintainer. Since these changes introduce a new
extension & API, the maintainer asks the Core Team for their opinion.
The Core Team agrees to accept the extension into XFree86.
3) Fox is not perfect, so bugs are found, and users suggest enhancements.
Fox submits patches for these things and eventually the XFree86 Core
Team believes that Fox is doing a good enough job that they offer to let him
become a Maintainer of the X-FILES extension code.
4) After a while, the protocol & API stabilizes, and Fox decides to declare
the 1.0 version of the spec is frozen.
5) Fox submits the X-FILES 1.0 specs to the X.org Architecture committee.
They decide to create a working group to study this.
6) All interested parties join the working group and discuss the proposed
spec. Changes are made as necessary, public review is held, and a
proposed standard spec is sent to the X.org Architecture committee.
7) The X.org Architecture committee approves the standard spec and the
X.org SSI committee tags the X-FILES code in the XFree86 tree as part
of the X.org SSI release.
Path B (Uniform Standards allow easier cross-platform development):
1) Fox creates a spec and submits to the X.org Architecture committee.
They decide to create a working group to study this.
2) All interested parties join the working group and discuss the proposed
spec.
3) A sample implementation is written to implement the spec in XFree86.
4) Fox submits his changes via the XFree86 bug tracking system, where they
are reviewed by a maintainer. Since these changes introduce a new
extension & API, the maintainer asks the Core Team for their opinion.
The Core Team either agrees to accept the extension into XFree86, or
to allow it only into the X.org SSI branch but not into the XFree86
branch.
5) Fox is not perfect, so bugs are found, and users suggest enhancements.
Fox submits patches for these things and eventually the XFree86 Core
Team believes that Fox is doing a good enough job that they offer to let him
become a Maintainer of the X-FILES extension code.
6) Based on the implementation experience, changes to the spec are made
as necessary, public review is held, and a proposed standard spec is
sent to the X.org Architecture committee.
7) The X.org Architecture committee approves the standard spec and the
X.org SSI committee tags the X-FILES code in the XFree86 tree as part
of the X.org SSI release.
_______________________________________________
Forum mailing list
Forum@XFree86.Org
http://XFree86.Org/mailman/listinfo/forum
-------------------------------------------------------
--
Best Regards,
Vadim Plessky
SVG Icons * BlueSphere Icons 0.3.0 released
http://svgicons.sourceforge.net
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic