summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAlan Coopersmith <alan.coopersmith@oracle.com>2013-07-10 21:19:27 -0700
committerAlan Coopersmith <alan.coopersmith@oracle.com>2013-07-10 21:19:31 -0700
commita17176a1b556e3306727ea7213f533cc0f4cccef (patch)
tree48c623c1df95f96a475def0da3f0b9062b35c533
parenta303b2577205c8f1681a1d2903569cbc3636977e (diff)
Fix lists to display as lists, not raw html code
-rw-r--r--Events/XDC2005.mdwn195
-rw-r--r--Events/XDC2013/CallForProposals.mdwn29
-rw-r--r--FAQMiscellaneous.mdwn59
-rw-r--r--Other/Press/CFP2012.mdwn19
-rw-r--r--X11R68PostPartumNotes.mdwn337
-rw-r--r--XorgTesting.mdwn159
6 files changed, 402 insertions, 396 deletions
diff --git a/Events/XDC2005.mdwn b/Events/XDC2005.mdwn
index 9b06f0e0..dddb1ba1 100644
--- a/Events/XDC2005.mdwn
+++ b/Events/XDC2005.mdwn
@@ -1,143 +1,142 @@
-
-
## X Developer's Meeting 2005
[[!table header="no" class="mointable" data="""
- **XDC 2005** | [[XDC 2006 >>|Events/XDC2006]]
+ **XDC 2005** | [[XDC 2006 >>|Events/XDC2006]]
"""]]
-We have scheduled a three day X Developer's meeting from Saturday, February 12, through Monday, February 14, at the Cambridge Research Laboratory (CRL) in Cambridge, Massachusetts.
+We have scheduled a three day X Developer's meeting from Saturday, February 12, through Monday, February 14, at the Cambridge Research Laboratory (CRL) in Cambridge, Massachusetts.
-**** The meeting is now full!!! ***
+**** The meeting is now full!!! ***
-This meeting is intended to cover a wide variety of topics about X Window System technologies, and the as yet unmet needs of the technologies that depend on the X Window System. As a result, this meeting is intended for people working across the entire X Window System stack, including toolkits and window managers and desktop infrastructure. This meeting is not, however, intended to cover general X application development topics or concepts.
+This meeting is intended to cover a wide variety of topics about X Window System technologies, and the as yet unmet needs of the technologies that depend on the X Window System. As a result, this meeting is intended for people working across the entire X Window System stack, including toolkits and window managers and desktop infrastructure. This meeting is not, however, intended to cover general X application development topics or concepts.
-There will be a number of people giving presentations or leading discussions. These presentations will likely consume no more than half of the overall meeting time so the remaining time can be spent with informal discussions, hacking, breakout sessions, etc.
+There will be a number of people giving presentations or leading discussions. These presentations will likely consume no more than half of the overall meeting time so the remaining time can be spent with informal discussions, hacking, breakout sessions, etc.
-If you wish to volunteer to give a presentation or lead a discussion, please send e-mail to [[xdevconf@lists.freedesktop.org|mailto:xdevconf@lists.freedesktop.org]]. In addition, if you have specific topics you'd like to see discussed in a presentation or during informal sessions, please send e-mail with your suggestions to that address as well.
+If you wish to volunteer to give a presentation or lead a discussion, please send e-mail to [[xdevconf@lists.freedesktop.org|mailto:xdevconf@lists.freedesktop.org]]. In addition, if you have specific topics you'd like to see discussed in a presentation or during informal sessions, please send e-mail with your suggestions to that address as well.
### Attend via Phone
-The phone bridge is not working. See below for Audio streaming.
+The phone bridge is not working. See below for Audio streaming.
### Attend via IRC
-IRC: freenode, #xdevconf
+IRC: freenode, #xdevconf
### Attend via Audio/Video feeds
-X developer's meeting audio and video feeds:
+X developer's meeting audio and video feeds:
-* Audio: Point gnomemeeting at gabe.freedesktop.org. First, go into Audio Codecs and disable everything but G.711-uLaw and G.711-ALaw; needs a bit more bandwidth but means you can actually hear what people are saying.
-* Vide:o Depending on your browser click on [[http://freedesktop.org:9192/|http://freedesktop.org:9192/]] or [[http://freedesktop.org/~keithp/webcam.html|http://freedesktop.org/~keithp/webcam.html]].
-Will video presentations be available somewhere? Are them recorded?
+* Audio: Point gnomemeeting at gabe.freedesktop.org. First, go into Audio Codecs and disable everything but G.711-uLaw and G.711-ALaw; needs a bit more bandwidth but means you can actually hear what people are saying.
+* Video: Depending on your browser click on [[http://freedesktop.org:9192/|http://freedesktop.org:9192/]] or [[http://freedesktop.org/~keithp/webcam.html|http://freedesktop.org/~keithp/webcam.html]].
+Will video presentations be available somewhere? Are them recorded?
### Presentation Agenda
-Current presentations for the X Developer's Meeting include:
+Current presentations for the X Developer's Meeting include:
#### Saturday, February 12
-* Starting at 9:00
-* Welcome, logistics, agenda, schedule bashing
- * Freedesktop Forum: What Problems Do We Need To Solve - Havoc Penningon, George Staikos, Jim Gettys
- * DND, Other Specification Issues - Owen Taylor and George Staikos
- * xrestop, xephyr, and X on handhelds - Mathew Allum ([[slides|http://www.o-hand.com/xmeet/]], [[demo|http://projects.o-hand.com/matchbox/demos.html]])
- * Testing Strategies - Stuart Anderson, Free Standards Group and X.org
- * Short Topics - All
+* Starting at 9:00
+* Welcome, logistics, agenda, schedule bashing
+ * Freedesktop Forum: What Problems Do We Need To Solve - Havoc Penningon, George Staikos, Jim Gettys
+ * DND, Other Specification Issues - Owen Taylor and George Staikos
+ * xrestop, xephyr, and X on handhelds - Mathew Allum ([[slides|http://www.o-hand.com/xmeet/]], [[demo|http://projects.o-hand.com/matchbox/demos.html]])
+ * Testing Strategies - Stuart Anderson, Free Standards Group and X.org
+ * Short Topics - All
#### Sunday, February 13
-* Starting at 9:00
- * X Proxy and Multicast Demo - David Flynn, Realm Systems
-* A Unified View of Improving X Desktop Rendering - The Owen Taylor, Søren Sandmann, Kristian Høgsberg and Diana Fong show
- * Cairo Status - Carl Worth, Red Hat (Slides: [[SVG|http://cairographics.org/talks/xdevconf_2005_02_13/svg]], [[HTML|http://cairographics.org/talks/xdevconf_2005_02_13/html]] [[PDF|http://cairographics.org/talks/xdevconf_2005_02_13/cairo.pdf]])
- * X Input Redirection - Deron Johnson, Keith Packard ([[Intro & Slides|http://lists.freedesktop.org/archives/xevie/2005-February/000039.html]])
- * A New Input System - Kristian Hogsberg, Jim Gettys
- * Polling And Scheduling in the X Main Loop - Kristian Høgsberg, Red Hat
- * Reworking the X server main loop, with proposed changes.
- * X and Media Support - Leon Shiman
- * 3D Graphics Pipelines - Nick Triantos, NVidia
+* Starting at 9:00
+ * X Proxy and Multicast Demo - David Flynn, Realm Systems
+ * A Unified View of Improving X Desktop Rendering - The Owen Taylor, Søren Sandmann, Kristian Høgsberg and Diana Fong show
+ * Cairo Status - Carl Worth, Red Hat (Slides: [[SVG|http://cairographics.org/talks/xdevconf_2005_02_13/svg]], [[HTML|http://cairographics.org/talks/xdevconf_2005_02_13/html]] [[PDF|http://cairographics.org/talks/xdevconf_2005_02_13/cairo.pdf]])
+ * X Input Redirection - Deron Johnson, Keith Packard ([[Intro & Slides|http://lists.freedesktop.org/archives/xevie/2005-February/000039.html]])
+ * A New Input System - Kristian Hogsberg, Jim Gettys
+ * Polling And Scheduling in the X Main Loop - Kristian Høgsberg, Red Hat
+ * Reworking the X server main loop, with proposed changes.
+ * X and Media Support - Leon Shiman
+ * 3D Graphics Pipelines - Nick Triantos, NVidia
#### Monday, February 14
-* Starting at 9:00
- * Open Source Legal discussion, Patents and Copyrights - Scott Peterson, Greg Jones, Linda Hamel, General Counsel, MA ITD (Information Technology Division)
- * X on GL - David Reveman, Novell
- * Mesa Solo - Jon Smirl
- * Merging fbdev and DRM - Jon Smirl
- * X.org Update - Audience
-Please all the people leave your presentations here so other people can see them.
+* Starting at 9:00
+ * Open Source Legal discussion, Patents and Copyrights - Scott Peterson, Greg Jones, Linda Hamel, General Counsel, MA ITD (Information Technology Division)
+ * X on GL - David Reveman, Novell
+ * Mesa Solo - Jon Smirl
+ * Merging fbdev and DRM - Jon Smirl
+ * X.org Update - Audience
+Please all the people leave your presentations here so other people can see them.
### Limited In-Person Attendance
-Due to space limitations, attendance will be limited to no more than 40 people, and we are almost full. If you would like to attend, please send mail to [[xdevconf@lists.freedesktop.org|mailto:xdevconf@lists.freedesktop.org]]. Having the names of attendees in advance eases building security, as we share the building with other companies.
+Due to space limitations, attendance will be limited to no more than 40 people, and we are almost full. If you would like to attend, please send mail to [[xdevconf@lists.freedesktop.org|mailto:xdevconf@lists.freedesktop.org]]. Having the names of attendees in advance eases building security, as we share the building with other companies.
-An audio feed will be made available for those attending remotely or unable to attend due to limitations on space. The meeting venue provides networking support with high speed Internet access.
+An audio feed will be made available for those attending remotely or unable to attend due to limitations on space. The meeting venue provides networking support with high speed Internet access.
-The hotels recommended near CRL are The Kendall Hotel, the Cambridge Marriott, and the Residence Inn. All three of these are a short walk from CRL and easily accessible via public transportation from the Kendall Square subway stop next to MIT. We have not negotiated any special rates with these hotels, so you'll need to shop around for the best rates, as they vary. A longer list of hotels is available at [[http://www.ai.mit.edu/visiting/hotels/hotels.shtml|http://www.ai.mit.edu/visiting/hotels/hotels.shtml]] . Directions to the lab can be found at: [[http://www.crl.hpl.hp.com/who/lab/directions.htm|http://www.crl.hpl.hp.com/who/lab/directions.htm]]
+The hotels recommended near CRL are The Kendall Hotel, the Cambridge Marriott, and the Residence Inn. All three of these are a short walk from CRL and easily accessible via public transportation from the Kendall Square subway stop next to MIT. We have not negotiated any special rates with these hotels, so you'll need to shop around for the best rates, as they vary. A longer list of hotels is available at [[http://www.ai.mit.edu/visiting/hotels/hotels.shtml|http://www.ai.mit.edu/visiting/hotels/hotels.shtml]] . Directions to the lab can be found at: [[http://www.crl.hpl.hp.com/who/lab/directions.htm|http://www.crl.hpl.hp.com/who/lab/directions.htm]]
### Currently Registered Attendees
-Currently registered attendees include:
-
- 1. Bill Abt
- 1. Matthew Allum
- 1. Paul Anderson
- 1. Stuart Anderson
- 1. Scott Balneves
- 1. David Boloker
- 1. Phil Blundell
- 1. Mirko Boehm
- 1. Alan Coopersmith
- 1. Egbert Eich
- 1. Mike Emmel
- 1. David Flynn
- 1. Nat Friedman
- 1. Diana Fong
- 1. Bdale Garbee
- 1. Jim Gettys
- 1. Jim Glutting
- 1. Linda Hamel
- 1. Mike A. Harris
- 1. Kristian Høgsberg
- 1. Mattias Hopf
- 1. Harold Hunt
- 1. Miguel de Icaza
- 1. Lars Knoll
- 1. Tommi Komulainen
- 1. Adam Jackson
- 1. Deron Johnson
- 1. Eric Kunze
- 1. Stewart Kreitman
- 1. Paul Litvak
- 1. Chris Lee
- 1. Lubos Lunak
- 1. Duncan Mak
- 1. Kevin Martin
- 1. Jim [[McQuillan|McQuillan]]
- 1. Nhan Nguyen
- 1. Keith Packard
- 1. Tapani Pälli
- 1. Havoc Pennington
- 1. Larry Rau
- 1. David Reveman
- 1. Andy Ritger
- 1. Robin Rowe
- 1. Zack Rusin
- 1. George Staikos
- 1. Søren Sandmann
- 1. Leon Shiman
- 1. Owen Taylor
- 1. Nick Triantos
- 1. Peter Winston
- 1. Carl Worth
- 1. Scott Peterson
- 1. Greg Jones
--- [[JimGettys|JimGettys]] - Feb. 13, 2005
+Currently registered attendees include:
+
+1. Bill Abt
+1. Matthew Allum
+1. Paul Anderson
+1. Stuart Anderson
+1. Scott Balneves
+1. David Boloker
+1. Phil Blundell
+1. Mirko Boehm
+1. Alan Coopersmith
+1. Egbert Eich
+1. Mike Emmel
+1. David Flynn
+1. Nat Friedman
+1. Diana Fong
+1. Bdale Garbee
+1. Jim Gettys
+1. Jim Glutting
+1. Linda Hamel
+1. Mike A. Harris
+1. Kristian Høgsberg
+1. Mattias Hopf
+1. Harold Hunt
+1. Miguel de Icaza
+1. Lars Knoll
+1. Tommi Komulainen
+1. Adam Jackson
+1. Deron Johnson
+1. Eric Kunze
+1. Stewart Kreitman
+1. Paul Litvak
+1. Chris Lee
+1. Lubos Lunak
+1. Duncan Mak
+1. Kevin Martin
+1. Jim [[McQuillan|McQuillan]]
+1. Nhan Nguyen
+1. Keith Packard
+1. Tapani Pälli
+1. Havoc Pennington
+1. Larry Rau
+1. David Reveman
+1. Andy Ritger
+1. Robin Rowe
+1. Zack Rusin
+1. George Staikos
+1. Søren Sandmann
+1. Leon Shiman
+1. Owen Taylor
+1. Nick Triantos
+1. Peter Winston
+1. Carl Worth
+1. Scott Peterson
+1. Greg Jones
+
+-- [[JimGettys|JimGettys]] - Feb. 13, 2005
diff --git a/Events/XDC2013/CallForProposals.mdwn b/Events/XDC2013/CallForProposals.mdwn
index 66fd2909..611e8473 100644
--- a/Events/XDC2013/CallForProposals.mdwn
+++ b/Events/XDC2013/CallForProposals.mdwn
@@ -2,22 +2,23 @@
# Call For Proposals
-**2013 X.Org Developers Conference (XDC 2013)**
- **23-25 September 2013**
- **Portland, Oregon USA**
+**2013 X.Org Developers Conference (XDC 2013)**
+ **23-25 September 2013**
+ **Portland, Oregon USA**
-The [[2013 X.Org Developers Conference|Events/XDC2013]] is the annual technical meeting for [[X Window System|http://x.org]] and [[Free Desktop|http://freedesktop.org]] developers. The attendees will gather to discuss outstanding technical issues related to X and to plan the direction of the X Window System and its software ecosystem. The event is free of charge and open to the general public.
+The [[2013 X.Org Developers Conference|Events/XDC2013]] is the annual technical meeting for [[X Window System|http://x.org]] and [[Free Desktop|http://freedesktop.org]] developers. The attendees will gather to discuss outstanding technical issues related to X and to plan the direction of the X Window System and its software ecosystem. The event is free of charge and open to the general public.
-The XDC 2013 Technical Program Committee (TPC) is requesting proposals for papers and presentations at XDC 2013. While any serious proposal will be gratefully considered, topics of interest to [[X.org|http://x.org]] and [[FreeDesktop.org|http://freedesktop.org]] developers are encouraged. There are three particular types of proposal the TPC is seeking:
+The XDC 2013 Technical Program Committee (TPC) is requesting proposals for papers and presentations at XDC 2013. While any serious proposal will be gratefully considered, topics of interest to [[X.Org|http://x.org]] and [[FreeDesktop.org|http://freedesktop.org]] developers are encouraged. There are three particular types of proposal the TPC is seeking:
- 1. Technical talk abstracts: 250-1000 words describing a presentation to be made at XDC 2013. This can be anything: a work-in-progress talk, a proposal for change, analysis of trends, etc.
- 1. Informal white papers: 1000+ words on something of interest or relevance to X.org developers, [[FreeDesktop|FreeDesktop]].org developers or the X community at large. These papers will appear in the online conference proceedings of XDC 2013, and are unrefereed (beyond basic checks for legitimacy and relevance). Papers can be refereed if requested in advance.
- 1. Technical research papers: 2500+ words in a format and style suitable for refereed technical publication. Papers that are judged acceptable by the TPC and its referees will be published in the printed conference proceedings of XDC 2013, available on a print-on-demand basis online.
-XDC 2013 technical presenters will be chosen from the authors of any of these submissions (as well as other presenters invited by the TPC).
+1. Technical talk abstracts: 250-1000 words describing a presentation to be made at XDC 2013. This can be anything: a work-in-progress talk, a proposal for change, analysis of trends, etc.
+1. Informal white papers: 1000+ words on something of interest or relevance to X.org developers, [[FreeDesktop|FreeDesktop]].org developers or the X community at large. These papers will appear in the online conference proceedings of XDC 2013, and are unrefereed (beyond basic checks for legitimacy and relevance). Papers can be refereed if requested in advance.
+1. Technical research papers: 2500+ words in a format and style suitable for refereed technical publication. Papers that are judged acceptable by the TPC and its referees will be published in the printed conference proceedings of XDC 2013, available on a print-on-demand basis online.
-Normally, there is time for everyone who wants to present to do so, but one can never tell. As much as possible, presenters will be selected from those who submit before the deadline. We also may be able to offer financial assistance for travel for presenters who could not otherwise afford to attend and who submit before the deadline. Please do submit your proposal in a timely fashion.
+XDC 2013 technical presenters will be chosen from the authors of any of these submissions (as well as other presenters invited by the TPC).
-**Proposals due:** Thursday 1 August 2013 17:00 UTC
- **Accepted formats:** PDF and ASCII text.
- **Notification of acceptance:** Thursday 8 August 2013
- **E-mail:** board at foundation.x.org
+Normally, there is time for everyone who wants to present to do so, but one can never tell. As much as possible, presenters will be selected from those who submit before the deadline. We also may be able to offer financial assistance for travel for presenters who could not otherwise afford to attend and who submit before the deadline. Please do submit your proposal in a timely fashion.
+
+**Proposals due:** Thursday 1 August 2013 17:00 UTC
+ **Accepted formats:** PDF and ASCII text.
+ **Notification of acceptance:** Thursday 8 August 2013
+ **E-mail:** board at foundation.x.org
diff --git a/FAQMiscellaneous.mdwn b/FAQMiscellaneous.mdwn
index 2057227e..6a46a3fe 100644
--- a/FAQMiscellaneous.mdwn
+++ b/FAQMiscellaneous.mdwn
@@ -2,48 +2,48 @@
# Miscellaneous
-[[!toc ]]
+[[!toc ]]
## I don't know my hardware, how can I configure X?
-Don't worry, todays configuration tools do a pretty good job detecting hardware automatically. If you are using a distribution you will want to try the configuration tools provided by your distribution vendor first. If these don't work or if your vendor doesn't provide any you can use the tools shipped with X.Org. You may want to use the graphical tool `xorgcfg` to do your Xserver configuration or you may let the server generate it's own configuration file by running: `X -configure` as root. It will create the configuration file `xorg.conf.new` in the home directory of the user who ran it (usually root). You should then copy this file to the default location `/etc/X11/xorg.conf`.
+Don't worry, todays configuration tools do a pretty good job detecting hardware automatically. If you are using a distribution you will want to try the configuration tools provided by your distribution vendor first. If these don't work or if your vendor doesn't provide any you can use the tools shipped with X.Org. You may want to use the graphical tool `xorgcfg` to do your Xserver configuration or you may let the server generate it's own configuration file by running: `X -configure` as root. It will create the configuration file `xorg.conf.new` in the home directory of the user who ran it (usually root). You should then copy this file to the default location `/etc/X11/xorg.conf`.
-Please note: Xorg can only autodetect PCI and AGP video chipsets. If you still use an ISA/EISA/VL chipset you need to at least know the chipset vendor to specify the correct driver. Most drivers can then autodetect the chipset model.
+Please note: Xorg can only autodetect PCI and AGP video chipsets. If you still use an ISA/EISA/VL chipset you need to at least know the chipset vendor to specify the correct driver. Most drivers can then autodetect the chipset model.
## How do I set the correct permissions of my Xserver binary?
-On UN*X like systems the server is usually owned by `root` and runs with the SUID bit set so that it runs with root privileges even if started by an ordinary user. To check if your Xserver has the right permissions you have to locate the server binary. Usually the soft link `/var/X11R6/bin/X` points to the binary. Please do
+On UN*X like systems the server is usually owned by `root` and runs with the SUID bit set so that it runs with root privileges even if started by an ordinary user. To check if your Xserver has the right permissions you have to locate the server binary. Usually the soft link `/var/X11R6/bin/X` points to the binary. Please do
[[!format txt """
ls -l /usr/X11R6/bin/X
"""]]
-obtain the binary the link points to (usually `/usr/X11R6/bin/Xorg` and do a:
+obtain the binary the link points to (usually `/usr/X11R6/bin/Xorg` and do a:
[[!format txt """
ls -l /usr/X11R6/bin/Xorg
"""]]
-(Replace `/usr/X11R6/bin/Xorg` with the name of the binary pointed to by the link.) The result should look something like this:
+(Replace `/usr/X11R6/bin/Xorg` with the name of the binary pointed to by the link.) The result should look something like this:
[[!format txt """
-rws--x--x 1 root root 2019033 2003-03-17 14:26 /usr/X11R6/bin/Xorg
"""]]
-This file is owned by the user 'root' and has the SUID bit set (the 's' in `-rws--x--x`. If either one isn't true you need to fix this. Do
+This file is owned by the user 'root' and has the SUID bit set (the 's' in `-rws--x--x`. If either one isn't true you need to fix this. Do
[[!format txt """
chown root:root /usr/X11R6/bin/Xorg
"""]]
-To make root owner of the file. (You have to be 'root' to do so). And
+To make root owner of the file. (You have to be 'root' to do so). And
[[!format txt """
chmod u+s /usr/X11R6/bin/Xorg
"""]]
-to set the SUID bit. (Here again you may have to replace `/usr/X11R6/bin/Xorg` by the name of the binary you are using.)
+to set the SUID bit. (Here again you may have to replace `/usr/X11R6/bin/Xorg` by the name of the binary you are using.)
## When I start X can I get the root window display a solid color instead of the 'root cross stitch'?
-Starting with version XFree86 4.3 there is the command line switch `-br` for the Xserver that changes the root window to a solid black. If you use `startx` please do:
+Starting with version XFree86 4.3 there is the command line switch `-br` for the Xserver that changes the root window to a solid black. If you use `startx` please do:
[[!format txt """
startx -- -br
"""]]
-Please note: It is not easy to use any other color than black or white. At this point there is no other colormap entry than black or white in the colormap.
+Please note: It is not easy to use any other color than black or white. At this point there is no other colormap entry than black or white in the colormap.
## My keyboard is dead, what can I do?
@@ -51,31 +51,31 @@ Please note: It is not easy to use any other color than black or white. At this
### I've upgraded to Xorg R6.7, now my keyboard is dead.
-You need a new set of keyboard description files in `/usr/X11R6/lib/X11/xkb/` that come with Xorg R6.7. Chances are that when you upgraded these files didn't get installed correctly. Try to reinstall these files and restart your Xserver.
+You need a new set of keyboard description files in `/usr/X11R6/lib/X11/xkb/` that come with Xorg R6.7. Chances are that when you upgraded these files didn't get installed correctly. Try to reinstall these files and restart your Xserver.
### My keyboard is still dead.
-There may be several reasons for this: You have an entry for a PS/2 mouse (on Linux on /dev/psaux) in your `xorg.conf` however you don't have a PS/2 mouse connected. This is actually a kernel problem. You should remove this device from your `xorg.conf`.
+There may be several reasons for this: You have an entry for a PS/2 mouse (on Linux on /dev/psaux) in your `xorg.conf` however you don't have a PS/2 mouse connected. This is actually a kernel problem. You should remove this device from your `xorg.conf`.
## I seem to be unable to allocate a sufficient number of colors in 8 bit.
-The RENDER extension preallocates some entries in the default colormap of the PseudoColor modes. This limits the number of entries available to clients. Some older 8bit clients are optimized for 254 entries in the 8bit palette (two are aloways set to white and black). If they cannot allocate all their colors they don't display correctly. In some cases changing a colormap entry is used to make certain objects blink. If there are not sufficient entries this blinking may not work. <br> You should make your software use a private colormap. If this isn't possible you can reduce the number or preallocated entries with a command line option to the Xserver: if you use `startx` to start your Xserver you can do: <br>
+The RENDER extension preallocates some entries in the default colormap of the PseudoColor modes. This limits the number of entries available to clients. Some older 8bit clients are optimized for 254 entries in the 8bit palette (two are aloways set to white and black). If they cannot allocate all their colors they don't display correctly. In some cases changing a colormap entry is used to make certain objects blink. If there are not sufficient entries this blinking may not work. <br> You should make your software use a private colormap. If this isn't possible you can reduce the number or preallocated entries with a command line option to the Xserver: if you use `startx` to start your Xserver you can do: <br>
[[!format txt """
startx -- -render mono
"""]]
-Please note that transparency or antialiasing may not work in this case.
+Please note that transparency or antialiasing may not work in this case.
## How do I set up a multihead configuration?
-I think there was a multihead FAQ someplace. I wonder where that's at? <br> Basically, you can have in the `xorg.conf` file:
+I think there was a multihead FAQ someplace. I wonder where that's at? <br> Basically, you can have in the `xorg.conf` file:
- 1. monitor section for that monitor.
- 1. device sections. One for each card. Use the !BusID token to specify which card is which.
- 1. screen sections. Each referencing the separate card, but both can reference the single monitor section.
- 1. server layout section that references both screens, eg:
+1. monitor section for that monitor.
+1. device sections. One for each card. Use the !BusID token to specify which card is which.
+1. screen sections. Each referencing the separate card, but both can reference the single monitor section.
+1. server layout section that references both screens, eg:
[[!format txt """
Section "ServerLayout"
@@ -86,24 +86,25 @@ Section "ServerLayout"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
"""]]
-Start with a working single head configuration and create the second device and screen sections by cutting and pasting but assigning different Identifiers and, in the case of the device sections, different !BusIDs. Change the layout section to something like above. <br> If you have a single card with one chipset but two (or more) display connectors you have to create device sections for each connector with identical busID. To distinguish between the connectors you need to add the line
+Start with a working single head configuration and create the second device and screen sections by cutting and pasting but assigning different Identifiers and, in the case of the device sections, different !BusIDs. Change the layout section to something like above. <br> If you have a single card with one chipset but two (or more) display connectors you have to create device sections for each connector with identical busID. To distinguish between the connectors you need to add the line
[[!format txt """
Screen n
"""]]
-* where `n` is replaced by the number of the connector. (ie. `n`0,1,2...=).
+* where `n` is replaced by the number of the connector. (ie. `n`0,1,2...=).
## How can I configure the Xserver bell (xkbbell) to use the sound subsystem of my computer? (ALSA, OSS, etc.)
-Answer (hopefully) goes here.. :)
+Answer (hopefully) goes here.. :)
## How do I find out which process owns a given window?
-The answer to this is not straightforward and depends on which assumptions you are willing/able to make and what your usage model is. The first thing that should be noted is that X is a network service, so it is not enough to simply know the PID alone, you will need to know both the PID and hostname of the client, in case the client is running on a remote machine.
+The answer to this is not straightforward and depends on which assumptions you are willing/able to make and what your usage model is. The first thing that should be noted is that X is a network service, so it is not enough to simply know the PID alone, you will need to know both the PID and hostname of the client, in case the client is running on a remote machine.
-That said, there is a standard method for X clients to report their hostname and PID. This is via two properties, _NET_WM_PID and WM_CLIENT_MACHINE. The idea behind these properties is that window managers can query them and use them to label windows graphically or otherwise make use of them. Your application code can also query them. However, there are several caveats:
+That said, there is a standard method for X clients to report their hostname and PID. This is via two properties, _NET_WM_PID and WM_CLIENT_MACHINE. The idea behind these properties is that window managers can query them and use them to label windows graphically or otherwise make use of them. Your application code can also query them. However, there are several caveats:
- 1. Their use is recommended but not required. Not all X clients set them.
- 1. Applications and toolkits that do set them often do so only on a single window which may not be anywhere close to either the root window or the "leaf" windows reported by mouse events. In this case, use of XQueryTree is required to traverse the window hierarchy to find it.
- 1. **Most Importantly, the contents of the properties is entirely within the control of the application itself!** This means that a malicious application could easily report false values!
-For anything more secure/robust you will need a server-side solution. Many local socket implementations provide a way to find out the PID of the remote end of a connection, such as getpeerucred(), which are kernel-based and cannot be spoofed. The server has a [[LocalClientCred|LocalClientCred]]() function that will return the values if supported. However, this will not work on remote connections.
+1. Their use is recommended but not required. Not all X clients set them.
+1. Applications and toolkits that do set them often do so only on a single window which may not be anywhere close to either the root window or the "leaf" windows reported by mouse events. In this case, use of XQueryTree is required to traverse the window hierarchy to find it.
+1. **Most Importantly, the contents of the properties is entirely within the control of the application itself!** This means that a malicious application could easily report false values!
+
+For anything more secure/robust you will need a server-side solution. Many local socket implementations provide a way to find out the PID of the remote end of a connection, such as getpeerucred(), which are kernel-based and cannot be spoofed. The server has a [[LocalClientCred|LocalClientCred]]() function that will return the values if supported. However, this will not work on remote connections.
diff --git a/Other/Press/CFP2012.mdwn b/Other/Press/CFP2012.mdwn
index 2166c0de..af13dcd9 100644
--- a/Other/Press/CFP2012.mdwn
+++ b/Other/Press/CFP2012.mdwn
@@ -1,15 +1,16 @@
-# Call For Proposals **2012 X.Org Developers Conference (XDC 2012)** **19-21 September 2012** **Nürnberg (Nuremberg), Germany**
+# Call For Proposals **2012 X.Org Developers Conference (XDC 2012)** **19-21 September 2012** **Nürnberg (Nuremberg), Germany**
-The [2012 X.Org Developers Conference] ([[http://www.x.org/wiki/Events/XDC2012|http://www.x.org/wiki/Events/XDC2012]]) is the annual technical meeting for [X Window System]([[http://x.org|http://x.org]]) and [Free Desktop]([[http://freedesktop.org|http://freedesktop.org]]) developers. The attendees will gather to discuss outstanding technical issues related to X and to plan the direction of the X Window System and its software ecosystem. The event is free of charge and open to the general public.
+The [2012 X.Org Developers Conference] ([[http://www.x.org/wiki/Events/XDC2012|http://www.x.org/wiki/Events/XDC2012]]) is the annual technical meeting for [X Window System]([[http://x.org|http://x.org]]) and [Free Desktop]([[http://freedesktop.org|http://freedesktop.org]]) developers. The attendees will gather to discuss outstanding technical issues related to X and to plan the direction of the X Window System and its software ecosystem. The event is free of charge and open to the general public.
-The XDC 2012 Technical Program Committee (TPC) is requesting proposals for papers and presentations at XDC 2012. While any serious proposal will be gratefully considered, topics of interest to X.org and [[FreeDesktop|FreeDesktop]].org developers are encouraged. There are three particular types of proposal the TPC is seeking:
+The XDC 2012 Technical Program Committee (TPC) is requesting proposals for papers and presentations at XDC 2012. While any serious proposal will be gratefully considered, topics of interest to X.org and [[FreeDesktop|FreeDesktop]].org developers are encouraged. There are three particular types of proposal the TPC is seeking:
- 1. Technical talk abstracts: 250-1000 words describing a presentation to be made at XDC 2012. This can be anything: a work-in-progress talk, a proposal for change, analysis of trends, etc.
- 1. Informal white papers: 1000+ words on something of interest or relevance to X.org developers, [[FreeDesktop|FreeDesktop]].org developers or the X community at large. These papers will appear in the online conference proceedings of XDC 2012, and are unrefereed (beyond basic checks for legitimacy and relevance). Papers can be refereed if requested in advance.
- 1. Technical research papers: 2500+ words in a format and style suitable for refereed technical publication. Papers that are judged acceptable by the TPC and its referees will be published in the printed conference proceedings of XDC 2012, available on a print-on-demand basis online.
-XDC 2012 technical presenters will be chosen from the authors of any of these submissions (as well as other presenters invited by the TPC).
+1. Technical talk abstracts: 250-1000 words describing a presentation to be made at XDC 2012. This can be anything: a work-in-progress talk, a proposal for change, analysis of trends, etc.
+1. Informal white papers: 1000+ words on something of interest or relevance to X.org developers, [[FreeDesktop|FreeDesktop]].org developers or the X community at large. These papers will appear in the online conference proceedings of XDC 2012, and are unrefereed (beyond basic checks for legitimacy and relevance). Papers can be refereed if requested in advance.
+1. Technical research papers: 2500+ words in a format and style suitable for refereed technical publication. Papers that are judged acceptable by the TPC and its referees will be published in the printed conference proceedings of XDC 2012, available on a print-on-demand basis online.
-Normally, there is time for everyone who wants to present to do so, but one can never tell. As much as possible, presenters will be selected from those who submit before the deadline. We also may be able to offer financial assistance for travel for presenters who could not otherwise afford to attend and who submit before the deadline. Please do submit your proposal in a timely fashion.
+XDC 2012 technical presenters will be chosen from the authors of any of these submissions (as well as other presenters invited by the TPC).
-**Proposals due:** Wednesday 15 August 2012 17:00 UTC *Accepted formats: PDF and ASCII text. **Notification of acceptance:** Monday 3 September 2012 **E-mail:** board at foundation.x.org
+Normally, there is time for everyone who wants to present to do so, but one can never tell. As much as possible, presenters will be selected from those who submit before the deadline. We also may be able to offer financial assistance for travel for presenters who could not otherwise afford to attend and who submit before the deadline. Please do submit your proposal in a timely fashion.
+
+**Proposals due:** Wednesday 15 August 2012 17:00 UTC *Accepted formats: PDF and ASCII text. **Notification of acceptance:** Monday 3 September 2012 **E-mail:** board at foundation.x.org
diff --git a/X11R68PostPartumNotes.mdwn b/X11R68PostPartumNotes.mdwn
index a6bdc9e8..88eb3e8d 100644
--- a/X11R68PostPartumNotes.mdwn
+++ b/X11R68PostPartumNotes.mdwn
@@ -2,185 +2,186 @@
# X.Org Foundation 6.8 release postpartum discussion notes
-[[!toc ]]
+[[!toc ]]
## Introduction
-These notes serve to document the tasks and issues that arose during the 6.8 release cycle and are intended to be a starting point for further discussion. They are arranged into the following general categories: scheduling, testing, and finalizing the release.
+These notes serve to document the tasks and issues that arose during the 6.8 release cycle and are intended to be a starting point for further discussion. They are arranged into the following general categories: scheduling, testing, and finalizing the release.
-While the discussion below mainly focuses on tasks that did not work well or need to be improved, it should be noted that the goal of the release team was not to perfect the release process but rather to improve it as much as possible. I (and, from the comment I received, many others) feel that the team was very successful and achieved its goal given the constraints of the release.
+While the discussion below mainly focuses on tasks that did not work well or need to be improved, it should be noted that the goal of the release team was not to perfect the release process but rather to improve it as much as possible. I (and, from the comment I received, many others) feel that the team was very successful and achieved its goal given the constraints of the release.
## Scheduling
-Discussion of this release started in late May 2004; however, due to the travel schedules of most X.Org Foundation BOD members, the schedule was not finalized until mid July 2004. The release was determined to be a time based release since it was driven by several companies (most notably Red Hat and SUSE) that needed to have a newer X Window System release for their upcoming products. Those companies needed to have the release ready at the beginning of September 2004, so the date for the release was initially set to 25 August 2004 in order to give a buffer for problems that might occur during the release cycle.
-
-The initial deadline for the release left us with a very tight schedule, which had several consequences.
-
- * The deadlines for the feature freeze and code freeze were severely compressed, which limited the features that could be added and limited the amount of testing that was possible.
- * A few bugs that would have otherwise have held up the release had to be postponed until after the release.
- * The number of new features added in this release was significant; however, most (if not all) had significant testing outside of the X.Org CVS tree before they were merged in. The majority of the remaining testing and bug fixing for these features were due to interactions they had with other new components.
- * It was challenging to keep people working on the features and bugs in order to meet the deadlines. Gentle pressure was applied in most cases to help motivate people on the critical paths. This will likely always be an issue for the release manager.
- * Because the release cycle was compressed, it was not difficult to keep people focused on the release. However, if the release cycle was longer, this will likely become a problem.
-The schedule was broken down into three phases: adding new features, fixing bugs and updating documentation. The deadlines were set approximately two weeks apart for each phase in order for the release to be completed by the initial target date.
-
-During the first phase, the tree was open to adding new features, fixing bugs and updating documentation. The primary responsibility was setting up the initial wiki pages to describe the release plan and status, making sure that the community members were aware of the release schedule and coordinating with the authors of the new code to make sure that everything was checked in before the feature freeze deadline. This phase went smoothly with only a small amount of additional work being required to encourage a few of the committers to have their code checked in before the deadline.
-
-After the feature freeze, the work was limited to fixing bugs and updating documentation. The source tree remained open to all committers to allow for the most people to find and fix bugs. For the release manager, the amount of time and effort required was significantly higher in this phase. The main tasks included:
-
- * Managing the blocker bug list
- * Holding regular release wranglers meetings (3 days/week)
- * Keeping people focused on fixing bugs
- * Reviewing and checking in fixes
- * Resolving conflicts
- * Encouraging testing (see testing section below)
-Several suggestions were made by the release wranglers to help with fixing bugs. The most important of which was the release bug, which is a commonly practiced method of managing a release. Bugs that were considered serious enough to hold up (i.e., block) the release should be marked as blocking the release bug. Bugzilla allows the release manager to list the dependency tree of all bugs that block the release. While there were several attempts to explain how this worked, there was still some confusion. For future releases, it should probably be explicitly explained on the release and status pages.
-
-The release wranglers met several times per week -- usually Monday, Wednesday and Friday mornings -- to focus on the blocker bugs and any issues that had come up during the previous few days. During these meetings, the release manager asked for (and usually got) volunteers to work on certain bugs. The remaining bugs were left to the release manager to investigate and resolve. These meetings were invaluable to the release manager.
-
-Since multiple people were working on fixing bugs at this time, the source tree remained open, which not only allowed the release wranglers to check-in fixes, but also allowed other members of the community to work on and fix issues. The release manager monitored all of the check-ins to make sure that new features were not being added to the release.
-
-Other important contributions during this stage came from those testing the release. There were quite a few people who were just staring to compile the tree and do testing. They reported bugs and marked them as blockers where appropriate. Some pre-packaged binaries were also made to help those who didn't have the experience of building the source tree, but could help with testing. These packages should be encouraged and made more formal in future releases. The general idea behind the testing for this release was loosely defined, but the details had not yet been worked out at this point, so the majority of the testing during this phase was devoted to build and daily usage testing.
-
-Two other bugs were added during this phase: the "hold open but not block the release" bug and the release notes bug. The "hold open" bug turned out to be the less useful of the two since there was too much other work to do that these did not get attention. It is possible that this bug might be more useful in future releases if the schedule is not so compressed. The release notes bug was very useful and over the course of the release cycle it became the place where all documentation issues were placed.
-
-This bug fixing phase was extended by three days to allow several major bug fixes to be completed and checked in. It could have been extended further, but the general feeling what that if we were going to keep on track for a late August release, then we should go ahead and freeze the code.
-
-After the code freeze, the work was limited to fixing all major blocker bugs and updating the documentation. As noted above, the transition between the previous phase and this one was rather arbitrary to keep the release on schedule; however, it turned out that the main difference was that instead of everyone else checking in bug fixes, the release manager was the only person allowed to check in changes. Bug fixes were being proposed and attached to the release blocker bugs, and the release manager and/or the release wranglers would evaluate the change (where possible) and apply the patch if it was accepted.
-
-Looking back, having all bug fixes funneled through a single person slowed down the bug fixing too much. For future releases, we should consider having a small team of people with write permission to continue to check in bugs during the critical bug fixing phase. Also, this transition phase should probably happen before the code freeze goes into effect, which would allow the code freeze phase to concentrate solely on documentation changes and last minute critical bug fixes.
-
-It was during this code freeze phase that the testing was finally formalized. Once the formal testing procedures were documented, many more people started testing the release. The test matrix was updated as time permitted and as new test reports came in. Ideally, the testing should have been happening much earlier, but due to the compressed time schedule the test procedures were not formalized until late in the process. See the next section on testing for more details of the formal testing requirements for this release.
-
-One action helped initiate the testing: tagging the tree with the first release candidate. This action along with the formalizing of the test procedure appeared to catalyze the community around the release. There were four release candidates tagged during this phase. Perhaps making snapshot tags in the previous release process and defining the test procedure earlier would have helped focus attention on testing before the code freeze.
-
-As active formal testing began, more bugs were found and fixed in a relatively short period of time, but it soon became clear that the release would not be able to happen on the original schedule. The number of bugs were remaining relatively constant during this time. At this time, a list of the current blocker bugs was sent out each night to the mailing list to let people know the state of each blocker bug.
-
-Over time the number of blocker bugs slowly shrank, and the focus shifted from bug fixing to updating the release documentation. Initially, the source tree was open to others making documentation only changes, but as the release neared, the source tree was closed to all but the release manager. At that time, the release notes bug became even more valuable to keep track of the features and bugs that needed to be documented.
-
-The documentation needed to be updated in several places. First, the release number is currently present in the following files in the xc/docs directory:
-
- * xc/doc/man/general/Standards.man
- * xc/doc/man/general/X.man
- * xc/doc/man/general/XOrg``Foundation.man
- * xc/doc/specs/BDF/bdf.ms
- * xc/doc/specs/CTEXT/ctext.tbl.ms
- * xc/doc/specs/FSProtocol/protocol.ms
- * xc/doc/specs/ICCCM/icccm.ms
- * xc/doc/specs/ICCCM/indexmacros.t
- * xc/doc/specs/ICE/ICElib.ms
- * xc/doc/specs/ICE/ice.ms
- * xc/doc/specs/SM/SMlib.ms
- * xc/doc/specs/SM/xsmp.ms
- * xc/doc/specs/X11/CH01
- * xc/doc/specs/X11/abstract.t
- * xc/doc/specs/X11/indexmacros.t
- * xc/doc/specs/XDMCP/xdmcp.ms
- * xc/doc/specs/XIM/xim.ms
- * xc/doc/specs/XLFD/xlfd.tbl.ms
- * xc/doc/specs/XProtocol/X11.protocol
- * xc/doc/specs/XProtocol/indexmacros.t
- * xc/doc/specs/Xaw/CH1
- * xc/doc/specs/Xaw/TPage_Credits
- * xc/doc/specs/Xaw/widg.idxmac.t
- * xc/doc/specs/Xext/DPMS.ms
- * xc/doc/specs/Xext/DPMSLib.ms
- * xc/doc/specs/Xext/bigreq.ms
- * xc/doc/specs/Xext/evi.ms
- * xc/doc/specs/Xext/record.ms
- * xc/doc/specs/Xext/recordlib.ms
- * xc/doc/specs/Xext/security.tex
- * xc/doc/specs/Xext/shape.ms
- * xc/doc/specs/Xext/shapelib.ms
- * xc/doc/specs/Xext/sync.tex
- * xc/doc/specs/Xext/synclib.tex
- * xc/doc/specs/Xext/tog-cup.ms
- * xc/doc/specs/Xext/xc-misc.ms
- * xc/doc/specs/Xi/library.ms
- * xc/doc/specs/Xi/porting.ms
- * xc/doc/specs/Xi/protocol.ms
- * xc/doc/specs/Xmu/Xmu.ms
- * xc/doc/specs/Xt/strings.mit
- * xc/doc/specs/i18n/Framework.ms
- * xc/doc/specs/i18n/LocaleDB.ms
- * xc/doc/specs/i18n/Trans.ms
-Note that the documentation listed above is current as of the 6.8 release, and might change in the future.
-
-The documentation in the xc/programs/Xserver/hw/xfree86/doc directory also needed to be updated. This documentation was built from the sgml files in the sgml subdir. The README, BUILD and RELNOTES sgml files will probably need to be updated with every release. The other files should be updated by their respective maintainers as needed. One special file, defs.ent, contains the macro definitions for the current and previous releases, and it was updated. Next, the old XFree86 doctools were required to build the sgml documentation. A few patches were required to build the tools (thanks to Soeren). Egbert added a README.build-docs file that describes what is needed to build and update the docs in the source tree.
-
-Once the documentation was complete, the last steps to finish the development phase of the release were:
-
- * Set the final version number and release date in the config/cf/xorg.cf and config/cf/cygwin.cf files
- * Tag the tree with the release tag, XORG-6_8_0
- * Create the release branch, XORG-6_8-branch
-It was noted in an earlier release wranglers call that the branch could have been created much earlier in the release. Due to the compressed time schedule, it was decided to hold off creating the branch until very late to keep people focused on the release, instead of on new development. This should be reevaluated for future releases.
-
-Additional discussion points:
-
- * How should new releases be scheduled (i.e., if someone has a need for a new release, what should they do to get it scheduled)?
- * Who/what determines the feature set for a new release?
- * When should the stable release branch be created? What are the consequences of creating it earlier or later in the release cycle?
- * Who should have write access to the source tree during the various stages of the release cycle?
- * When should the tree be tagged for snapshots and release candidates?
- * Should the documentation be updated to a more modern format? If so, should all docs be updated?
+Discussion of this release started in late May 2004; however, due to the travel schedules of most X.Org Foundation BOD members, the schedule was not finalized until mid July 2004. The release was determined to be a time based release since it was driven by several companies (most notably Red Hat and SUSE) that needed to have a newer X Window System release for their upcoming products. Those companies needed to have the release ready at the beginning of September 2004, so the date for the release was initially set to 25 August 2004 in order to give a buffer for problems that might occur during the release cycle.
+
+The initial deadline for the release left us with a very tight schedule, which had several consequences.
+
+ * The deadlines for the feature freeze and code freeze were severely compressed, which limited the features that could be added and limited the amount of testing that was possible.
+ * A few bugs that would have otherwise have held up the release had to be postponed until after the release.
+ * The number of new features added in this release was significant; however, most (if not all) had significant testing outside of the X.Org CVS tree before they were merged in. The majority of the remaining testing and bug fixing for these features were due to interactions they had with other new components.
+ * It was challenging to keep people working on the features and bugs in order to meet the deadlines. Gentle pressure was applied in most cases to help motivate people on the critical paths. This will likely always be an issue for the release manager.
+ * Because the release cycle was compressed, it was not difficult to keep people focused on the release. However, if the release cycle was longer, this will likely become a problem.
+The schedule was broken down into three phases: adding new features, fixing bugs and updating documentation. The deadlines were set approximately two weeks apart for each phase in order for the release to be completed by the initial target date.
+
+During the first phase, the tree was open to adding new features, fixing bugs and updating documentation. The primary responsibility was setting up the initial wiki pages to describe the release plan and status, making sure that the community members were aware of the release schedule and coordinating with the authors of the new code to make sure that everything was checked in before the feature freeze deadline. This phase went smoothly with only a small amount of additional work being required to encourage a few of the committers to have their code checked in before the deadline.
+
+After the feature freeze, the work was limited to fixing bugs and updating documentation. The source tree remained open to all committers to allow for the most people to find and fix bugs. For the release manager, the amount of time and effort required was significantly higher in this phase. The main tasks included:
+
+ * Managing the blocker bug list
+ * Holding regular release wranglers meetings (3 days/week)
+ * Keeping people focused on fixing bugs
+ * Reviewing and checking in fixes
+ * Resolving conflicts
+ * Encouraging testing (see testing section below)
+Several suggestions were made by the release wranglers to help with fixing bugs. The most important of which was the release bug, which is a commonly practiced method of managing a release. Bugs that were considered serious enough to hold up (i.e., block) the release should be marked as blocking the release bug. Bugzilla allows the release manager to list the dependency tree of all bugs that block the release. While there were several attempts to explain how this worked, there was still some confusion. For future releases, it should probably be explicitly explained on the release and status pages.
+
+The release wranglers met several times per week -- usually Monday, Wednesday and Friday mornings -- to focus on the blocker bugs and any issues that had come up during the previous few days. During these meetings, the release manager asked for (and usually got) volunteers to work on certain bugs. The remaining bugs were left to the release manager to investigate and resolve. These meetings were invaluable to the release manager.
+
+Since multiple people were working on fixing bugs at this time, the source tree remained open, which not only allowed the release wranglers to check-in fixes, but also allowed other members of the community to work on and fix issues. The release manager monitored all of the check-ins to make sure that new features were not being added to the release.
+
+Other important contributions during this stage came from those testing the release. There were quite a few people who were just staring to compile the tree and do testing. They reported bugs and marked them as blockers where appropriate. Some pre-packaged binaries were also made to help those who didn't have the experience of building the source tree, but could help with testing. These packages should be encouraged and made more formal in future releases. The general idea behind the testing for this release was loosely defined, but the details had not yet been worked out at this point, so the majority of the testing during this phase was devoted to build and daily usage testing.
+
+Two other bugs were added during this phase: the "hold open but not block the release" bug and the release notes bug. The "hold open" bug turned out to be the less useful of the two since there was too much other work to do that these did not get attention. It is possible that this bug might be more useful in future releases if the schedule is not so compressed. The release notes bug was very useful and over the course of the release cycle it became the place where all documentation issues were placed.
+
+This bug fixing phase was extended by three days to allow several major bug fixes to be completed and checked in. It could have been extended further, but the general feeling what that if we were going to keep on track for a late August release, then we should go ahead and freeze the code.
+
+After the code freeze, the work was limited to fixing all major blocker bugs and updating the documentation. As noted above, the transition between the previous phase and this one was rather arbitrary to keep the release on schedule; however, it turned out that the main difference was that instead of everyone else checking in bug fixes, the release manager was the only person allowed to check in changes. Bug fixes were being proposed and attached to the release blocker bugs, and the release manager and/or the release wranglers would evaluate the change (where possible) and apply the patch if it was accepted.
+
+Looking back, having all bug fixes funneled through a single person slowed down the bug fixing too much. For future releases, we should consider having a small team of people with write permission to continue to check in bugs during the critical bug fixing phase. Also, this transition phase should probably happen before the code freeze goes into effect, which would allow the code freeze phase to concentrate solely on documentation changes and last minute critical bug fixes.
+
+It was during this code freeze phase that the testing was finally formalized. Once the formal testing procedures were documented, many more people started testing the release. The test matrix was updated as time permitted and as new test reports came in. Ideally, the testing should have been happening much earlier, but due to the compressed time schedule the test procedures were not formalized until late in the process. See the next section on testing for more details of the formal testing requirements for this release.
+
+One action helped initiate the testing: tagging the tree with the first release candidate. This action along with the formalizing of the test procedure appeared to catalyze the community around the release. There were four release candidates tagged during this phase. Perhaps making snapshot tags in the previous release process and defining the test procedure earlier would have helped focus attention on testing before the code freeze.
+
+As active formal testing began, more bugs were found and fixed in a relatively short period of time, but it soon became clear that the release would not be able to happen on the original schedule. The number of bugs were remaining relatively constant during this time. At this time, a list of the current blocker bugs was sent out each night to the mailing list to let people know the state of each blocker bug.
+
+Over time the number of blocker bugs slowly shrank, and the focus shifted from bug fixing to updating the release documentation. Initially, the source tree was open to others making documentation only changes, but as the release neared, the source tree was closed to all but the release manager. At that time, the release notes bug became even more valuable to keep track of the features and bugs that needed to be documented.
+
+The documentation needed to be updated in several places. First, the release number is currently present in the following files in the xc/docs directory:
+
+ * xc/doc/man/general/Standards.man
+ * xc/doc/man/general/X.man
+ * xc/doc/man/general/XOrg``Foundation.man
+ * xc/doc/specs/BDF/bdf.ms
+ * xc/doc/specs/CTEXT/ctext.tbl.ms
+ * xc/doc/specs/FSProtocol/protocol.ms
+ * xc/doc/specs/ICCCM/icccm.ms
+ * xc/doc/specs/ICCCM/indexmacros.t
+ * xc/doc/specs/ICE/ICElib.ms
+ * xc/doc/specs/ICE/ice.ms
+ * xc/doc/specs/SM/SMlib.ms
+ * xc/doc/specs/SM/xsmp.ms
+ * xc/doc/specs/X11/CH01
+ * xc/doc/specs/X11/abstract.t
+ * xc/doc/specs/X11/indexmacros.t
+ * xc/doc/specs/XDMCP/xdmcp.ms
+ * xc/doc/specs/XIM/xim.ms
+ * xc/doc/specs/XLFD/xlfd.tbl.ms
+ * xc/doc/specs/XProtocol/X11.protocol
+ * xc/doc/specs/XProtocol/indexmacros.t
+ * xc/doc/specs/Xaw/CH1
+ * xc/doc/specs/Xaw/TPage_Credits
+ * xc/doc/specs/Xaw/widg.idxmac.t
+ * xc/doc/specs/Xext/DPMS.ms
+ * xc/doc/specs/Xext/DPMSLib.ms
+ * xc/doc/specs/Xext/bigreq.ms
+ * xc/doc/specs/Xext/evi.ms
+ * xc/doc/specs/Xext/record.ms
+ * xc/doc/specs/Xext/recordlib.ms
+ * xc/doc/specs/Xext/security.tex
+ * xc/doc/specs/Xext/shape.ms
+ * xc/doc/specs/Xext/shapelib.ms
+ * xc/doc/specs/Xext/sync.tex
+ * xc/doc/specs/Xext/synclib.tex
+ * xc/doc/specs/Xext/tog-cup.ms
+ * xc/doc/specs/Xext/xc-misc.ms
+ * xc/doc/specs/Xi/library.ms
+ * xc/doc/specs/Xi/porting.ms
+ * xc/doc/specs/Xi/protocol.ms
+ * xc/doc/specs/Xmu/Xmu.ms
+ * xc/doc/specs/Xt/strings.mit
+ * xc/doc/specs/i18n/Framework.ms
+ * xc/doc/specs/i18n/LocaleDB.ms
+ * xc/doc/specs/i18n/Trans.ms
+Note that the documentation listed above is current as of the 6.8 release, and might change in the future.
+
+The documentation in the xc/programs/Xserver/hw/xfree86/doc directory also needed to be updated. This documentation was built from the sgml files in the sgml subdir. The README, BUILD and RELNOTES sgml files will probably need to be updated with every release. The other files should be updated by their respective maintainers as needed. One special file, defs.ent, contains the macro definitions for the current and previous releases, and it was updated. Next, the old XFree86 doctools were required to build the sgml documentation. A few patches were required to build the tools (thanks to Soeren). Egbert added a README.build-docs file that describes what is needed to build and update the docs in the source tree.
+
+Once the documentation was complete, the last steps to finish the development phase of the release were:
+
+ * Set the final version number and release date in the config/cf/xorg.cf and config/cf/cygwin.cf files
+ * Tag the tree with the release tag, XORG-6_8_0
+ * Create the release branch, XORG-6_8-branch
+It was noted in an earlier release wranglers call that the branch could have been created much earlier in the release. Due to the compressed time schedule, it was decided to hold off creating the branch until very late to keep people focused on the release, instead of on new development. This should be reevaluated for future releases.
+
+Additional discussion points:
+
+ * How should new releases be scheduled (i.e., if someone has a need for a new release, what should they do to get it scheduled)?
+ * Who/what determines the feature set for a new release?
+ * When should the stable release branch be created? What are the consequences of creating it earlier or later in the release cycle?
+ * Who should have write access to the source tree during the various stages of the release cycle?
+ * When should the tree be tagged for snapshots and release candidates?
+ * Should the documentation be updated to a more modern format? If so, should all docs be updated?
## Testing
-For the release to be successful and accepted by the community, it was determined very early in the release cycle that testing the release would need to be a priority. The testing was broken down into two parts: what platforms were to be tested and what tests were to be run on those platforms. During OLS, Stuart Anderson and I discussed both of these issues and then presented it to the BOD.
+For the release to be successful and accepted by the community, it was determined very early in the release cycle that testing the release would need to be a priority. The testing was broken down into two parts: what platforms were to be tested and what tests were to be run on those platforms. During OLS, Stuart Anderson and I discussed both of these issues and then presented it to the BOD.
-First, we determined that, given the scheduling constraints, it would not be possible to test all possible OS vendor, release, architecture, video card combinations, so a subset was proposed as sufficient. These included the operating system, the architecture, the distribution and release version number. Each combination would define a platform to be tested.
+First, we determined that, given the scheduling constraints, it would not be possible to test all possible OS vendor, release, architecture, video card combinations, so a subset was proposed as sufficient. These included the operating system, the architecture, the distribution and release version number. Each combination would define a platform to be tested.
-Next, we proposed a set of tests to be run on those platforms. The list included build, install, conformance and run test categories, and we outlined what was required to pass each test category. The tests as well as the platforms were organized into a matrix and was added to the freedesktop wiki:
+Next, we proposed a set of tests to be run on those platforms. The list included build, install, conformance and run test categories, and we outlined what was required to pass each test category. The tests as well as the platforms were organized into a matrix and was added to the freedesktop wiki:
- * [[http://wiki.x.org/wiki/X11R68ReleaseStatus|http://wiki.x.org/wiki/X11R68ReleaseStatus]]
-On that page, the test matrix was included and instructions were given for running each of the tests. Initially the instructions were quite sparse, but as more people ran the tests, they were expanded and improved.
+ * [[http://wiki.x.org/wiki/X11R68ReleaseStatus|http://wiki.x.org/wiki/X11R68ReleaseStatus]]
+On that page, the test matrix was included and instructions were given for running each of the tests. Initially the instructions were quite sparse, but as more people ran the tests, they were expanded and improved.
-In the test matrix, the first three columns of each row defined one platform to be tested, and the last four columns displayed the state of the testing on that platform. Entries were labeled with the release candidate version that was tested and were given a green background if the test passed or a red background if the test failed (or had not yet been tested).
+In the test matrix, the first three columns of each row defined one platform to be tested, and the last four columns displayed the state of the testing on that platform. Entries were labeled with the release candidate version that was tested and were given a green background if the test passed or a red background if the test failed (or had not yet been tested).
-Names responsible for testing (or gathering the test information) were put into the fourth column in an attempt to give people some ownership and responsibility for testing a particular platform. This was moderately successful; however, there were a few problems with this system:
+Names responsible for testing (or gathering the test information) were put into the fourth column in an attempt to give people some ownership and responsibility for testing a particular platform. This was moderately successful; however, there were a few problems with this system:
- * The release schedule was incredibly tight and it was not possible to fully test all of the platforms listed.
- * The amount of time to run through all of the tests was on the order or 8+ hours (on a 1GHz PC running Linux). Other platforms were significantly slower and some took days to complete the tests.
- * Finding volunteers for testing (i.e., adding their name to the table) was not difficult as this was done early in the process, but it was not managed well enough. Clear responsibilities should have been outlined so that this process could have been self-starting and self-regulating.
- * Updating the test matrix was cumbersome. Either giving this responsibility to those that volunteered to test a particular platform or automating it so that anyone can update the table would be better. The process for this release required that the release manager monitor the mailing list and update the release matrix as new reports came in.
- * By the time the testing had begun, it quickly became clear that there were problems with the tests, which had to be addressed before any testing could truly begin. These problems were worked out within a few days, but the delay caused confusion and slowed down the testing process, and ultimately led to the release being delayed.
- * There was also confusion about exactly which tests could be run on each platform. Certain tests could only be run on Linux systems, and comparable tests were not investigated for other platforms.
- * The X test suite used was chosen for expediency and ease of use. It was not necessarily the best one available.
-The initial goal for testing was to fill in the entire test matrix before the final release. However, it became clear to the release wranglers during the release cycle that the test matrix would not be completely filled, so the goal was changed to fill in as much of the matrix as possible before the release.
+ * The release schedule was incredibly tight and it was not possible to fully test all of the platforms listed.
+ * The amount of time to run through all of the tests was on the order or 8+ hours (on a 1GHz PC running Linux). Other platforms were significantly slower and some took days to complete the tests.
+ * Finding volunteers for testing (i.e., adding their name to the table) was not difficult as this was done early in the process, but it was not managed well enough. Clear responsibilities should have been outlined so that this process could have been self-starting and self-regulating.
+ * Updating the test matrix was cumbersome. Either giving this responsibility to those that volunteered to test a particular platform or automating it so that anyone can update the table would be better. The process for this release required that the release manager monitor the mailing list and update the release matrix as new reports came in.
+ * By the time the testing had begun, it quickly became clear that there were problems with the tests, which had to be addressed before any testing could truly begin. These problems were worked out within a few days, but the delay caused confusion and slowed down the testing process, and ultimately led to the release being delayed.
+ * There was also confusion about exactly which tests could be run on each platform. Certain tests could only be run on Linux systems, and comparable tests were not investigated for other platforms.
+ * The X test suite used was chosen for expediency and ease of use. It was not necessarily the best one available.
+The initial goal for testing was to fill in the entire test matrix before the final release. However, it became clear to the release wranglers during the release cycle that the test matrix would not be completely filled, so the goal was changed to fill in as much of the matrix as possible before the release.
-As noted above, testing is a very time consuming process and certain tests lend themselves to automation. Many people do not have the extra test machines required to do run tests; however, for those that do, automating the test process would certainly make it more likely that testing would be done. One key tool that automated part of the testing procedure was tinderbox. It allowed us to quickly notice when recent check-ins broke the build process. During many of the release wranglers calls, tinderbox and related tools were discussed, and it was generally agreed that these tools should be explored further to help automate as many of the tests as possible.
+As noted above, testing is a very time consuming process and certain tests lend themselves to automation. Many people do not have the extra test machines required to do run tests; however, for those that do, automating the test process would certainly make it more likely that testing would be done. One key tool that automated part of the testing procedure was tinderbox. It allowed us to quickly notice when recent check-ins broke the build process. During many of the release wranglers calls, tinderbox and related tools were discussed, and it was generally agreed that these tools should be explored further to help automate as many of the tests as possible.
-Additional discussion points:
+Additional discussion points:
- * What else should be done to improve the test instructions?
- * How can the test matrix be better managed?
+ * What else should be done to improve the test instructions?
+ * How can the test matrix be better managed?
## Finalizing the release
-Once the main development tasks were complete (as outlined above in the schedule section), the release was ready to be packaged and distributed to the community. This finalization stage included building the tarballs and documentation, uploading everything to the appropriate websites and handling the announcement/press release.
-
-Historically, the source code for each public release is made available through a set of tarballs. Egbert created a script to automate creating the set of tarballs from a checked out source tree. Here is an outline of the steps involved (to be run as root):
-
- 1. Create a new directory that will hold the release
- * `mkdir /tmp/release`
- 1. Export the tagged tree to this new dir
- * `cd /tmp/release`
- * `cvs export -r XORG-6_8_0 xc`
- 1. Untar Egbert's build scripts and cd to that directory
- 1. Create a directory to hold the tarballs and run the source script
- * `mkdir final`
- * `cd final`
- * `../source /tmp/release`
- 1. Rename the tarballs to the appropriate names for the current release
- * `cd source/bindist`
- * `mv Xsrc1.tgz X11R6.8.0-src1.tar.gz`
- * _Repeat for each of the other src files_
-Currently, there are seven tarballs created. Their contents are described in the README file that is shipped with the release (and can be found in the documentation on the website -- see below).
-
-In addition to the multiple tarballs, it was later determined during the 6.8.1 update release that creating one large tarball containing all source code was desirable. From the web logs, more people downloaded the one large tarball than the set of smaller ones.
-
-The website on freedesktop includes not only the tarballs (above) but also the documentation for the release. The website is arranged as follows:
+Once the main development tasks were complete (as outlined above in the schedule section), the release was ready to be packaged and distributed to the community. This finalization stage included building the tarballs and documentation, uploading everything to the appropriate websites and handling the announcement/press release.
+
+Historically, the source code for each public release is made available through a set of tarballs. Egbert created a script to automate creating the set of tarballs from a checked out source tree. Here is an outline of the steps involved (to be run as root):
+
+1. Create a new directory that will hold the release
+ * `mkdir /tmp/release`
+1. Export the tagged tree to this new dir
+ * `cd /tmp/release`
+ * `cvs export -r XORG-6_8_0 xc`
+1. Untar Egbert's build scripts and cd to that directory
+1. Create a directory to hold the tarballs and run the source script
+ * `mkdir final`
+ * `cd final`
+ * `../source /tmp/release`
+1. Rename the tarballs to the appropriate names for the current release
+ * `cd source/bindist`
+ * `mv Xsrc1.tgz X11R6.8.0-src1.tar.gz`
+ * _Repeat for each of the other src files_
+
+Currently, there are seven tarballs created. Their contents are described in the README file that is shipped with the release (and can be found in the documentation on the website -- see below).
+
+In addition to the multiple tarballs, it was later determined during the 6.8.1 update release that creating one large tarball containing all source code was desirable. From the web logs, more people downloaded the one large tarball than the set of smaller ones.
+
+The website on freedesktop includes not only the tarballs (above) but also the documentation for the release. The website is arranged as follows:
[[!format txt """
X11R6.8.0/
binaries/
@@ -190,26 +191,26 @@ The website on freedesktop includes not only the tarballs (above) but also the d
src/
src-single/
"""]]
-The binaries directory contains the pre-compiled binaries for various operating system releases. At this time, no pre-compiled binaries are being made available. We should consider doing this for future releases.
+The binaries directory contains the pre-compiled binaries for various operating system releases. At this time, no pre-compiled binaries are being made available. We should consider doing this for future releases.
-The doc directory contains the html formatted documentation for the full release. This documentation is taken from `ProjectRoot/lib/X11/doc/html` after doing both a "make install" and a "make install.man" from a full build of the release. These html files also reference the PDF docs, so the PDF sibling directory should contain the documentation from `ProjectRoot/lib/X11/doc/PDF`.
+The doc directory contains the html formatted documentation for the full release. This documentation is taken from `ProjectRoot/lib/X11/doc/html` after doing both a "make install" and a "make install.man" from a full build of the release. These html files also reference the PDF docs, so the PDF sibling directory should contain the documentation from `ProjectRoot/lib/X11/doc/PDF`.
-The src directory contains the set of seven tarballs (described above) along with the md5sums file. The md5sums file can be created with the following command: "md5sum *.tar.* > md5sums". The src-single dir contains the single source tarballs and their own md5sums. For the 6.8.1 release, two single source tarballs were created: one in gzipped tar format and one in bzip2'd tar format. The bzip2 compressed tarball was added since it has become very popular and is smaller than the gzip compressed tarball.
+The src directory contains the set of seven tarballs (described above) along with the md5sums file. The md5sums file can be created with the following command: "md5sum *.tar.* > md5sums". The src-single dir contains the single source tarballs and their own md5sums. For the 6.8.1 release, two single source tarballs were created: one in gzipped tar format and one in bzip2'd tar format. The bzip2 compressed tarball was added since it has become very popular and is smaller than the gzip compressed tarball.
-The patches directory is normally empty for full releases (i.e., releases that have a patch number of 0). For patch releases, this directory would contain the patches necessary to bring the release from the previous full or patch release up-to-date with the current patch release. See the 6.8.1 release for an example.
+The patches directory is normally empty for full releases (i.e., releases that have a patch number of 0). For patch releases, this directory would contain the patches necessary to bring the release from the previous full or patch release up-to-date with the current patch release. See the 6.8.1 release for an example.
-The next task of the finalization process is creating the press release. This task took quite a while to get appropriate quotes from members of the community, companies, etc. so it is suggested for future releases that it be started well in advance of the preparation of the website documentation and tarballs. There are other steps required here, but since I was not involved with this task, I will leave it to others to describe the process.
+The next task of the finalization process is creating the press release. This task took quite a while to get appropriate quotes from members of the community, companies, etc. so it is suggested for future releases that it be started well in advance of the preparation of the website documentation and tarballs. There are other steps required here, but since I was not involved with this task, I will leave it to others to describe the process.
-The goal was to complete the tasks described above and make the release available to the community on 9 September 2004. Unfortunately, several problems occurred and important lessons were learned about how to handle the release announcements:
+The goal was to complete the tasks described above and make the release available to the community on 9 September 2004. Unfortunately, several problems occurred and important lessons were learned about how to handle the release announcements:
-Many people were very excited about this release, and we hope that the excitement and enthusiasm carries over to future releases. However, there were some who snooped around the website and found the source tarballs before the official announcement had been made, and this got reported to slashdot. Since the X.Org website had not been updated and the press releases had not been finalized, this pre-announcement by slashdot caused confusion and "stole the thunder" from the official announcement. The lesson here is that the documentation and tarballs should be embargoed in a completely private place that no one other than those involved in the finalization stage have access to.
+Many people were very excited about this release, and we hope that the excitement and enthusiasm carries over to future releases. However, there were some who snooped around the website and found the source tarballs before the official announcement had been made, and this got reported to slashdot. Since the X.Org website had not been updated and the press releases had not been finalized, this pre-announcement by slashdot caused confusion and "stole the thunder" from the official announcement. The lesson here is that the documentation and tarballs should be embargoed in a completely private place that no one other than those involved in the finalization stage have access to.
-The X.Org website and freedesktop website need to be made public at very nearly the same time. The official website should be X.Org with freedesktop as a mirror. However, since few people have access to the X.Org website, the freedesktop site was set up first and the X.Org site files were copied from there. This could have been handled better by embargoing the release.
+The X.Org website and freedesktop website need to be made public at very nearly the same time. The official website should be X.Org with freedesktop as a mirror. However, since few people have access to the X.Org website, the freedesktop site was set up first and the X.Org site files were copied from there. This could have been handled better by embargoing the release.
-The press release needs to be prepared well ahead of time so that the official announcement sent to the press/mailing lists and the unveiling of the websites can be done simultaneously.
+The press release needs to be prepared well ahead of time so that the official announcement sent to the press/mailing lists and the unveiling of the websites can be done simultaneously.
-Discussion points:
+Discussion points:
- * How much ahead of time does the press release need to be sent to the appropriate press outlets in order for it to be released at a specific time (i.e., the time that the embargo is lifted)?
- * What other mirror sites are available? What should be done to coordinate with them to make the release available on their sites as soon as possible after the announcement?
--- [[KevinMartin|http://wiki.freedesktop.org/wiki/KevinMartin]] - 29 Sep 2004 (updated for [[MoinMoin|MoinMoin]] 02 Mar 2005)
+ * How much ahead of time does the press release need to be sent to the appropriate press outlets in order for it to be released at a specific time (i.e., the time that the embargo is lifted)?
+ * What other mirror sites are available? What should be done to coordinate with them to make the release available on their sites as soon as possible after the announcement?
+-- [[KevinMartin|http://wiki.freedesktop.org/wiki/KevinMartin]] - 29 Sep 2004 (updated for [[MoinMoin|MoinMoin]] 02 Mar 2005)
diff --git a/XorgTesting.mdwn b/XorgTesting.mdwn
index 05897dbc..4b57235c 100644
--- a/XorgTesting.mdwn
+++ b/XorgTesting.mdwn
@@ -5,114 +5,117 @@
## Detailed test instructions
-This section outlines the test procedure to follow when testing a release candidate. When a test run has been completed, please e-mail the [[xorg@lists.freedesktop.org|mailto:xorg@lists.freedesktop.org]] mailing list with the following information so that we can track what has and has not yet been tested. Note that we are interested in progress: please do not wait to complete all phases of testing to send in reports.
-
- 1. Your Name
- 1. The date tested
- 1. The platform you tested:
- * The operating system tested (e.g., AIX, Cygwin, FreeBSD, HP-UX, Linux, etc.)
- * The architecture tested (e.g., Alpha, AMD64, EM64T, IA-32, IA-64, Sparc, etc.)
- * The distribution and release tested (e.g., Red Hat FC2, SUSE 9.1, Debian unstable, Solaris 9, etc.)
- 1. The snapshot or release candidate tag tested (e.g., XORG-6_7_99_1, etc.)
- 1. Build test status: passed or failed or untested
- 1. Install test status: passed or failed or untested
- 1. Conformance test status: passed or failed or untested
- 1. Run test status: passed or failed or untested
- * List the tests run
-For any test(s) that failed, please include in your report the test(s) that failed, and file a bugzilla report if no one has already filed one against the failure(s) you found.
+This section outlines the test procedure to follow when testing a release candidate. When a test run has been completed, please e-mail the [[xorg@lists.freedesktop.org|mailto:xorg@lists.freedesktop.org]] mailing list with the following information so that we can track what has and has not yet been tested. Note that we are interested in progress: please do not wait to complete all phases of testing to send in reports.
+
+1. Your Name
+1. The date tested
+1. The platform you tested:
+ * The operating system tested (e.g., AIX, Cygwin, FreeBSD, HP-UX, Linux, etc.)
+ * The architecture tested (e.g., Alpha, AMD64, EM64T, IA-32, IA-64, Sparc, etc.)
+ * The distribution and release tested (e.g., Red Hat FC2, SUSE 9.1, Debian unstable, Solaris 9, etc.)
+1. The snapshot or release candidate tag tested (e.g., XORG-6_7_99_1, etc.)
+1. Build test status: passed or failed or untested
+1. Install test status: passed or failed or untested
+1. Conformance test status: passed or failed or untested
+1. Run test status: passed or failed or untested
+ * List the tests run
+For any test(s) that failed, please include in your report the test(s) that failed, and file a bugzilla report if no one has already filed one against the failure(s) you found.
### Build tests
-Each of the following build tests can be performed by copying the _sample_ host.def file (or the _alternate_) to the xc/config/cf directory and the running `make World >& World.LOG` (or other such command as appropriate for your platform), and then checking the World.LOG file for any failures.
+Each of the following build tests can be performed by copying the _sample_ host.def file (or the _alternate_) to the xc/config/cf directory and the running `make World >& World.LOG` (or other such command as appropriate for your platform), and then checking the World.LOG file for any failures.
- 1. Build with empty host.def file ([[sample|http://www.freedesktop.org/~kem/build-tests/1/host.def]] [[alternate|http://www.freedesktop.org/~kem/build-tests/1a/host.def]])
- 1. Build with [[BuildServersOnly|BuildServersOnly]] defined as YES ([[sample|http://www.freedesktop.org/~kem/build-tests/2/host.def]] [[alternate|http://www.freedesktop.org/~kem/build-tests/2a/host.def]])
- 1. Build with [[DoLoadableServer|DoLoadableServer]] defined as NO ([[sample|http://www.freedesktop.org/~kem/build-tests/3/host.def]] [[alternate|http://www.freedesktop.org/~kem/build-tests/3a/host.def]])
-Note that some systems do not have a compatible version of Freetype2 installed on their system, so in addition to each build requirement above, defining [[HasFreetype2|HasFreetype2]] as NO is permitted. Each _alternate_ host.def file above have this define included.
+1. Build with empty host.def file ([[sample|http://www.freedesktop.org/~kem/build-tests/1/host.def]] [[alternate|http://www.freedesktop.org/~kem/build-tests/1a/host.def]])
+1. Build with [[BuildServersOnly|BuildServersOnly]] defined as YES ([[sample|http://www.freedesktop.org/~kem/build-tests/2/host.def]] [[alternate|http://www.freedesktop.org/~kem/build-tests/2a/host.def]])
+1. Build with [[DoLoadableServer|DoLoadableServer]] defined as NO ([[sample|http://www.freedesktop.org/~kem/build-tests/3/host.def]] [[alternate|http://www.freedesktop.org/~kem/build-tests/3a/host.def]])
+Note that some systems do not have a compatible version of Freetype2 installed on their system, so in addition to each build requirement above, defining [[HasFreetype2|HasFreetype2]] as NO is permitted. Each _alternate_ host.def file above have this define included.
### Install tests
-Each of the following install tests can be performed by building the release (as described above using the _sample_ or _alternate_ host.def file provided), running `make Install >& Install.LOG` (or other such command as appropriate for your platform), and checking the Install.LOG output for any failures.
+Each of the following install tests can be performed by building the release (as described above using the _sample_ or _alternate_ host.def file provided), running `make Install >& Install.LOG` (or other such command as appropriate for your platform), and checking the Install.LOG output for any failures.
- 1. Build and install with no host.def file ([[sample|http://www.freedesktop.org/~kem/install-tests/1/host.def]] [[alternate|http://www.freedesktop.org/~kem/install-tests/1a/host.def]])
- 1. Build and install with: Project``Root defined to be something other than the default, and Nothing``Outside``Project``Root defined as YES ([[sample|http://www.freedesktop.org/~kem/install-tests/2/host.def]] [[alternate|http://www.freedesktop.org/~kem/install-tests/2a/host.def]])
-Note that some systems do not have a compatible version of Freetype2 installed on their system, so in addition to each install requirement above, defining Has``Freetype2 as NO is permitted. Each _alternate_ host.def file above have this define included.
+1. Build and install with no host.def file ([[sample|http://www.freedesktop.org/~kem/install-tests/1/host.def]] [[alternate|http://www.freedesktop.org/~kem/install-tests/1a/host.def]])
+1. Build and install with: Project``Root defined to be something other than the default, and Nothing``Outside``Project``Root defined as YES ([[sample|http://www.freedesktop.org/~kem/install-tests/2/host.def]] [[alternate|http://www.freedesktop.org/~kem/install-tests/2a/host.def]])
+Note that some systems do not have a compatible version of Freetype2 installed on their system, so in addition to each install requirement above, defining Has``Freetype2 as NO is permitted. Each _alternate_ host.def file above have this define included.
### Conformance tests
-After installing the full release, the conformance tests can be run using the X test suite, which can be downloaded [[here|http://www.freedesktop.org/~kem/testing/xtest.tar.gz]]. A helper script (called ``xreg``) is used to run the X test suite, which can be downloaded [[here|http://www.freedesktop.org/~kem/testing/xreg]]. See the next two sections below for more information on how to setup and use these tools.
+After installing the full release, the conformance tests can be run using the X test suite, which can be downloaded [[here|http://www.freedesktop.org/~kem/testing/xtest.tar.gz]]. A helper script (called ``xreg``) is used to run the X test suite, which can be downloaded [[here|http://www.freedesktop.org/~kem/testing/xreg]]. See the next two sections below for more information on how to setup and use these tools.
#### Setting up the X test suite
-Here are some brief instructions on how to download and set up everything that you will need to run the X test suite:
+Here are some brief instructions on how to download and set up everything that you will need to run the X test suite:
- 1. Follow the directions at [[BuildingXtest|BuildingXtest]]
- 1. `wget http://www.freedesktop.org/~kem/testing/xreg`
-Now you should be ready to begin testing.
+1. Follow the directions at [[BuildingXtest|BuildingXtest]]
+1. `wget http://www.freedesktop.org/~kem/testing/xreg`
+
+Now you should be ready to begin testing.
#### Examples of how to use the xreg script
-Here are some examples of how to use xreg to run the X test suite:
-
- 1. `xreg -xtest -xvfb`
- * This runs xtest at all default depths using the Xvfb server.
- * The default depths are 8, 15, 16, and 24+32.
- * The "24+32" depth is one that uses a depth of 24 with a frame buffer bits per pixel of 32 (i.e., -depth 24 -fbbpp 32).
- 1. `xreg -xtest -xorg -d 16`
- * This runs xtest at depth 16 using the Xorg server.
- 1. `xreg -xtest -xvfb -d 15 -test XCopyArea`
- * This runs xtest at depth 15 using the Xvfb server, but it only runs the XCopy``Area test.
- * Selecting individual tests is very useful to track down test failures.
- 1. `xreg -xtest -xvfb -d 16 -xvfbwidth 1280 -xvfbheight 1024 -test XFillRectangles -n 3-5`
- * This runs xtest at depth 16 using the Xvfb server running at 1280x1024, but only runs the third through the fifth tests of the XFill``Rectangles test.
-Notes on using xreg:
-
- * The output from these test runs are stored in `pwd`/results by default. You can change the default output dir using the -O command line option.
- * The material below assumes that you have done a full install of the system to /usr/X11``R6. However, if you are using a different Project``Root, you can use the following command line option to the xreg script to run from that alternate location: `-projroot` _path-to-your-project-root_
- * The files that are generated from an xreg run of xtest are:
- 1. `X-setup..output` -- this file contains the output of the X server during the setup phase
- 1. `xtest.DEPTH.DATE.TIME.errors` -- this file contains the list of errors found during the test run at depth _DEPTH_ made on date _DATE_ at time _TIME_.
- 1. `xtest.DEPTH.DATE.TIME.report` -- this file contains the report of all tests run at depth _DEPTH_ made on date _DATE_ at time _TIME_.
- 1. `xtest.DEPTH.DATE.TIME.summary` -- this file contains a summary of the errors found during the test run at depth _DEPTH_ made on date _DATE_ at time _TIME_. The summary file is only useful during full test runs (e.g., not when running individual tests).
- 1. `xtest.DEPTH.DATE.TIME.results` -- this directory contains the journal from the tests run at depth _DEPTH_ made on date _DATE_ at time _TIME_ as well as any error images generated.
- * After running xtest, you can check to see if everything passed by looking at the summary/errors/report file(s) to see if there are any failures.
- * There are some known failures that the summary file attempts to take into account. The first part of the summary file is the list of failures, and at the end of the summary file is a diff between the known failures (e.g., XDraw``Arcs) and what the failures were for this run.
- * The xreg script has only been tested on Linux systems. If there are problems with these scripts, please post patches to the [[xorg@lists.freedesktop.org|mailto:xorg@lists.freedesktop.org]] mailing list.
- * There are many other options to xreg (and it can be used to run other tests such as x11perf). Run `xreg -help` to see the usage message.
+Here are some examples of how to use xreg to run the X test suite:
+
+1. `xreg -xtest -xvfb`
+ * This runs xtest at all default depths using the Xvfb server.
+ * The default depths are 8, 15, 16, and 24+32.
+ * The "24+32" depth is one that uses a depth of 24 with a frame buffer bits per pixel of 32 (i.e., -depth 24 -fbbpp 32).
+1. `xreg -xtest -xorg -d 16`
+ * This runs xtest at depth 16 using the Xorg server.
+1. `xreg -xtest -xvfb -d 15 -test XCopyArea`
+ * This runs xtest at depth 15 using the Xvfb server, but it only runs the XCopy``Area test.
+ * Selecting individual tests is very useful to track down test failures.
+1. `xreg -xtest -xvfb -d 16 -xvfbwidth 1280 -xvfbheight 1024 -test XFillRectangles -n 3-5`
+ * This runs xtest at depth 16 using the Xvfb server running at 1280x1024, but only runs the third through the fifth tests of the XFill``Rectangles test.
+Notes on using xreg:
+
+ * The output from these test runs are stored in `pwd`/results by default. You can change the default output dir using the -O command line option.
+ * The material below assumes that you have done a full install of the system to /usr/X11``R6. However, if you are using a different Project``Root, you can use the following command line option to the xreg script to run from that alternate location: `-projroot` _path-to-your-project-root_
+ * The files that are generated from an xreg run of xtest are:
+ 1. `X-setup..output` -- this file contains the output of the X server during the setup phase
+ 1. `xtest.DEPTH.DATE.TIME.errors` -- this file contains the list of errors found during the test run at depth _DEPTH_ made on date _DATE_ at time _TIME_.
+ 1. `xtest.DEPTH.DATE.TIME.report` -- this file contains the report of all tests run at depth _DEPTH_ made on date _DATE_ at time _TIME_.
+ 1. `xtest.DEPTH.DATE.TIME.summary` -- this file contains a summary of the errors found during the test run at depth _DEPTH_ made on date _DATE_ at time _TIME_. The summary file is only useful during full test runs (e.g., not when running individual tests).
+ 1. `xtest.DEPTH.DATE.TIME.results` -- this directory contains the journal from the tests run at depth _DEPTH_ made on date _DATE_ at time _TIME_ as well as any error images generated.
+ * After running xtest, you can check to see if everything passed by looking at the summary/errors/report file(s) to see if there are any failures.
+ * There are some known failures that the summary file attempts to take into account. The first part of the summary file is the list of failures, and at the end of the summary file is a diff between the known failures (e.g., XDraw``Arcs) and what the failures were for this run.
+ * The xreg script has only been tested on Linux systems. If there are problems with these scripts, please post patches to the [[xorg@lists.freedesktop.org|mailto:xorg@lists.freedesktop.org]] mailing list.
+ * There are many other options to xreg (and it can be used to run other tests such as x11perf). Run `xreg -help` to see the usage message.
#### Actually running the conformance tests
-For this section, one of the following should be used for testing:
+For this section, one of the following should be used for testing:
+
+ * For platforms based on a XFree86-style DDX, the ``dummy`` driver should be used.
+ * For example: `xreg -xtest -xorg`
+ * This will run xtest at all the default depths using the Xorg server.
+ * Check the output of each report or summary file to make sure that all tests that are expected to pass do actually pass.
+ * For all other platforms, ``Xvfb`` should be used.
+ * For example: `xreg -xtest -xvfb -d "15 16 24+32"`
+ * This will run xtest at depths 15, 16 and 24+32 using the Xvfb server.
+ * Check the output of each report or summary file to make sure that all tests that are expected to pass do actually pass.
+ * Note that Xvfb does not currently run at depth 8, so the example above limits the testing to depths 15, 16 and 24+32. Update, this problem has been fixed in CVS now and Xvfb at depth 8 works again.
- * For platforms based on a XFree86-style DDX, the ``dummy`` driver should be used.
- * For example: `xreg -xtest -xorg`
- * This will run xtest at all the default depths using the Xorg server.
- * Check the output of each report or summary file to make sure that all tests that are expected to pass do actually pass.
- * For all other platforms, ``Xvfb`` should be used.
- * For example: `xreg -xtest -xvfb -d "15 16 24+32"`
- * This will run xtest at depths 15, 16 and 24+32 using the Xvfb server.
- * Check the output of each report or summary file to make sure that all tests that are expected to pass do actually pass.
- * Note that Xvfb does not currently run at depth 8, so the example above limits the testing to depths 15, 16 and 24+32. Update, this problem has been fixed in CVS now and Xvfb at depth 8 works again.
-Additional notes:
+Additional notes:
- * The ``Xvfb`` server is special X server that uses a virtual framebuffer. It is normally built and installed with the full release. See the `Xvfb(1)` for more information about this server.
- * The ``dummy`` driver is a special driver available with the XFree86 DDX. To use the dummy driver, simply substitue it for your normal card driver in the `Device` section of your `xorg.conf` configuration file. For example, if you normally uses an ati driver, then you will have a `Device` section with `Driver "ati"` to let the X server know that you want it to load and use the ati driver; however, for these conformance tests, you would change that line to `Driver "dummy"` and remove any other ati specific options from the `Device` section.
+ * The ``Xvfb`` server is special X server that uses a virtual framebuffer. It is normally built and installed with the full release. See the `Xvfb(1)` for more information about this server.
+ * The ``dummy`` driver is a special driver available with the XFree86 DDX. To use the dummy driver, simply substitue it for your normal card driver in the `Device` section of your `xorg.conf` configuration file. For example, if you normally uses an ati driver, then you will have a `Device` section with `Driver "ati"` to let the X server know that you want it to load and use the ati driver; however, for these conformance tests, you would change that line to `Driver "dummy"` and remove any other ati specific options from the `Device` section.
### Run tests
-After installing the full release, you can run the subset of tests listed below that applies to the platform being tested. Please run these tests on at least two different driver families (where applicable). For example, on an IA-32 system running Linux, you could run the tests using one card from the ATI driver family and another card from the NVIDIA driver family.
+After installing the full release, you can run the subset of tests listed below that applies to the platform being tested. Please run these tests on at least two different driver families (where applicable). For example, on an IA-32 system running Linux, you could run the tests using one card from the ATI driver family and another card from the NVIDIA driver family.
+
+Tests for each driver family:
-Tests for each driver family:
+1. X test suite (listed above)
+1. x11perf
+1. rendertest (found in the xapps CVS repository on freedesktop.org)
+1. Standard graphical environment
+1. GL tests: glxgears, gloss, [[quake3|http://www.freedesktop.org/~jg/quake3.tar.gz]]
+1. Switch to/from VTs (on Linux)
- 1. X test suite (listed above)
- 1. x11perf
- 1. rendertest (found in the xapps CVS repository on freedesktop.org)
- 1. Standard graphical environment
- 1. GL tests: glxgears, gloss, [[quake3|http://www.freedesktop.org/~jg/quake3.tar.gz]]
- 1. Switch to/from VTs (on Linux)
--- [[KevinMartin|KevinMartin]] - 18 Jan 2005
+-- [[KevinMartin|KevinMartin]] - 18 Jan 2005